[BUG] Mirth Versions 4.4.1 and 4.4.2 custom-lib folder needs to be empty for web service listener channel to start

[clarksss]

Describe the bug From the versions I have tested, Mirth Versions 4.4.1 and 4.4.2 custom-lib folder needs to be empty for web service listener channel to start

To Reproduce Setup steps (if required). Example:

1. add any file to that blank c:\program files\mirth connect\custom-lib folder
2. (I simply tested with a .txt and .jar file)
3. create a new channel with a "Web Service Listener" - default settings
4. deploy channel and it won't start

Steps to reproduce the behavior:

1. Go to c:\program files\mirth connect\custom-lib
2. Add a file
3. In Mirth Connect, click Settings
4. click the Resources tab
5. click Reload Resource
6. go to (click) Channels on the left menu bar
7. Deploy the Web Service Listener channel
8. Notice the channel does not start.

Expected behavior A channel with Web Service Listener will start after deploying with custom-lib having .jar files in there to access and use in integrations.

Actual behavior A channel with Web Service Listener will NOT start after deploying channel with custom-lib having .jar files (or any files) in there

Screenshots after file exists in custom-lib folder and resource loaded and channel re-deployed

Environment (please complete the following information):

• OS: Windows Server 2019 Datacenter
• 
• 
• Connect Versions Tested 4.4.1, 4.4.2

Workaround(s) check this box, under the resources tab.. this seemed allow the channel to start.

Additional context works in Mirth Connect 3.9.1 with Java 10.0.1 (I have not tested the versions in between 3.9.1 to 4.4.0)

[clarksss]

ERROR when trying to start the Channel:

[2023-11-22 10:01:28.898] ERROR (com.mirth.connect.server.channel.ErrorTaskHandler:26): com.mirth.connect.donkey.server.StartException: Failed to start channel test web service (b125f74f-fd94-4b46-b277-16bf7077bb43).

at com.mirth.connect.donkey.server.channel.Channel.start(Channel.java:792)

at com.mirth.connect.server.controllers.DonkeyEngineController$DeployTask.doDeploy(DonkeyEngineController.java:2031)

at com.mirth.connect.server.controllers.DonkeyEngineController$DeployTask.execute(DonkeyEngineController.java:1835)

at com.mirth.connect.server.channel.ChannelTask.call(ChannelTask.java:67)

at com.mirth.connect.server.channel.ChannelTask.call(ChannelTask.java:16)

at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)

at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)

at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

at java.base/java.lang.Thread.run(Thread.java:834)

Caused by: java.lang.NullPointerException

at javax.xml.ws.Endpoint.create(Endpoint.java:161)

at com.mirth.connect.connectors.ws.WebServiceReceiver.onStart(WebServiceReceiver.java:209)

at com.mirth.connect.donkey.server.channel.SourceConnector.start(SourceConnector.java:106)

at com.mirth.connect.donkey.server.channel.Channel.start(Channel.java:768)

... 8 more

[pacmano1]

@clarksss did @narupley 's suggestion on your forum post not work?

Forum link for reference for others: https://forums.mirthproject.io/forum/mirth-connect/support/184120-web-service-listener-not-starting-since-upgrade-from-mirth-connect-3-9-1-to-4-4-1

Most likely that is a bug in JAX-WS. Something like this: https://github.com/jakartaee/jax-ws-api/issues/161

We're still including the old javax.xml.ws module, so perhaps at some point we should upgrade to the newer jakarta.xml.ws (and probably break a lot of Web Service channels in the process...)

Anyway you can either uncheck that Default resource in your channel's Summary -> Set Dependencies -> Library Resources

Or, go to Settings -> Resources and check "Load Parent-First" on the Default resource, which seems to workaround the jax-ws bug too (because it's a classloader issue).

[clarksss]

Yes , put a checkmark in there, seemed to get the channel to start ! thanks ! ☺

From: pacmano1 @.> Sent: Wednesday, November 22, 2023 11:17 AM To: nextgenhealthcare/connect @.> Cc: Clark, Stace [IH] @.>; Mention @.> Subject: Re: [nextgenhealthcare/connect] [BUG] Mirth Versions 4.4.1 and 4.4.2 custom-lib folder needs to be empty for web service listener channel to start (Issue #5997)

CAUTION! This email originated from outside of Interior Health. Do not click links or open attachments unless you recognize the sender, their email address, and know the content is safe. If you suspect this is a phishing or fraudulent email please forward it to @.**@.>.

@clarkssshttps://github.com/clarksss did @narupleyhttps://github.com/narupley 's suggestion on your forum post not work?

Forum link for reference for others: https://forums.mirthproject.io/forum/mirth-connect/support/184120-web-service-listener-not-starting-since-upgrade-from-mirth-connect-3-9-1-to-4-4-1

— Reply to this email directly, view it on GitHubhttps://github.com/nextgenhealthcare/connect/issues/5997#issuecomment-1823360247, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BEF5YMPY34KDQYAAP2IK4ETYFZFUDAVCNFSM6AAAAAA7WUJGLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRTGM3DAMRUG4. You are receiving this because you were mentioned.Message ID: @.**@.>>

[ChristopherSchultz]

I experienced the same issue moving from Mirth 4.1.1 on Java 8 to Mirth 4.4.2 on Java 11 (Amazon Coretto). I have changed the "Default Resource" (aka custom-lib) to parent-first behavior and my channels will deploy and start, now.

[ChristopherSchultz]

After testing, my SOAP-based services are working exactly as expected after enabling parent-first load-order.

[narupley]

Looks like my forum response was already copied above, but yeah, it sounds like this is a defect in the JAX-WS implementation library itself. At some point we should upgrade to the newer jakarta implementation (just a fork/continuation of the javax library I think), where it looks like that has already been fixed.

[jgarrett4674]

I had the same issue starting a web service listener with custom-libs loaded when we upgraded to 4.4.1. I added the following to the mirth vmoptions files and it resolved the issue: -Djavax.xml.ws.spi.Provider=com.sun.xml.ws.spi.ProviderImpl I found this resolution in https://github.com/jakartaee/jax-ws-api/issues/161