search

nextgenhealthcare / connect

The swiss army knife of healthcare integration.
Other
868 stars 265 forks source link

[BUG] JMS Listener/Reader no longer works with ActiveMQ #6111

Closed fallensieg closed 1 week ago

fallensieg commented 4 months ago

Describe the bug JMS Sender/Listener channels no longer work with ActiveMQ.

To Reproduce I have several JMS Sender / Listener channels with ActiveMQ (5.15.11) working fine in Mirth 4.0.1 Now I'm trying to upgrade Mirth to 4.4.2 and when I try to send a message to ActiveMQ I get the error: org.apache.activemq.ActiveMQConnectionFactory cannot be cast to javax.jms.ConnectionFactory

imatge.png​

I've tried to downgrade to Mirth 4.3 and the error is the same, but with Mirth 4.2 it works again. Have also tired upgrading to 4.5, same problem. Am I doing something wrong, or could it be a bug from Mirth 4.3 and above? Anyone knows a workaround for this issue?

Expected behavior JMS Listener and Sender can read/write messages against ActiveMQ.

Actual behavior Channels will not even start with the following error message

Caused by: java.lang.ClassCastException: class org.apache.activemq.ActiveMQConnectionFactory cannot be cast to class javax.jms.ConnectionFactory (org.apache.activemq.ActiveMQConnectionFactory is in unnamed module of loader com.mirth.connect.server.util.ChildFirstURLClassLo ader @17f0d6e; javax.jms.ConnectionFactory is in unnamed module of loader java.net.URLClassLoader @3970ed7e) at com.mirth.connect.connectors.jms.JmsClient.start(J msClient.java:129)

Environment (please complete the following information):

Workaround(s) Would be intered in knowing.

Additional context Add any other context about the problem here.

pacmano1 commented 4 months ago

Maybe upload a sample channel?

ab-mg-23 commented 4 months ago

The problem is using a resource to load the ActiveMQ Client library and commit fd3b7b2 changing the child classloader to take effect before the cast from the concrete ActiveMQConnectionFactory to the ConnectionFactory interface. The interface definition is in a different classloader than the concrete definition, so Java throws an error on the cast. If you move the client JAR and dependencies into server-lib/jms that should load everything from the same classloader as a workaround, but then run the risk of classpath issues with dependencies.

fallensieg commented 4 months ago

Thank you @ab-mg-23. That was exactly the issue and doing what you've suggested has resolved my problem.

hae-andrew-young commented 3 months ago

Adding this for reference. More people are seeing this issue. https://forums.mirthproject.io/forum/mirth-connect/support/184548-jms-sender-and-activemq

hae-andrew-young commented 3 months ago

If you move the client JAR and dependencies into server-lib/jms that should load everything from the same classloader as a workaround, but then run the risk of classpath issues with dependencies.

This didn't work for me. Still getting the ClassCastException

frankparth8 commented 3 weeks ago

Getting this exact same error. Tried copying jars into server-lib/jms with no success.

Using the following jars: jakarta.jms-api-3.0.0 & activemq-client-6.1.2 @fallensieg Can you please let me know which exact jars you used that worked?

Attached a screenshot of the channel settings as well! This is on Mirth 4.5.0 with a Windows 2022 Datacenter hosted by AWS.

What testing was performed before this PR was approved and change was released? channelSettings

ab-mg-23 commented 3 weeks ago

@frankparth8 You'll need to use the ActiveMQ 5.18.x version of the client. The 6.X baseline moved from javax.jms to jakarta.jms for the API definition but Mirth still uses the JMS 1.1 API.

frankparth8 commented 3 weeks ago

@ab-mg-23 That seems to have done the trick! I used 5.18.4 to avoid a security issue. Also had to add hawtbuf/1.11 due to another issue that was there. Thanks for the help!

frankparth8 commented 2 weeks ago

Sure thing! Basically this was with a Windows 2022 Datacenter running Java

  1. It's hard to say without your exact error but with the configuration shown in the screenshot above I had to add the following jars to the server-lib/jms (not custom-lib) folder: activemq-client-5.18.4 + javax.jms-api-2.0.1 + hawtbuf-1.11

On Wed, Jun 12, 2024 at 5:56 AM André Schulze @.***> wrote:

@frankparth8 https://github.com/frankparth8 Hello, can you please explain in detail what you did? I've the same problem with Mirth 4.5 + Java 17 + UbuntuServer 22. I copied "activemq-all-5.18.4.jar" into "server-lib/jms/" but it didn't solve the problem. Thanks in advance.

— Reply to this email directly, view it on GitHub https://github.com/nextgenhealthcare/connect/issues/6111#issuecomment-2162942363, or unsubscribe https://github.com/notifications/unsubscribe-auth/AILKKAZJ5LECR6QFQNRPIZLZHBAOJAVCNFSM6AAAAABDS3OOA2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRSHE2DEMZWGM . You are receiving this because you were mentioned.Message ID: @.***>

-- Frank Parth

Senior Principal Engineer Laguna Niguel, CA 949-426-2294 *LinkedIn https://www.linkedin.com/in/frank-parth-8047145a/ | * Spinn Solutions http://spinnsolutions.com/

lmillergithub commented 1 week ago

In 4.3.0 we added the ability to specify whether resources should load classes "child-first" or "parent-first". Previously, all resource classloaders loaded "parent-first". This meant that when a user attempted to use a class that is already included with Mirth Connect, such as a PostgreSQL driver, the class was loaded from the parent classloader instead of loading the custom version that the user wanted. The user can now achieve the desired behavior using a "child-first" classloader. We have also made "child-first" the default option. I was able to get around this error by selecting the 'Load Parent-First' on the resource tab for the activeMQ resource.