| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Problem with Java class loaders and shared libraries |
« View previous topic :: View next topic » |
| Author |
Message
|
| pmarie |
 Posted: Fri Jul 26, 2019 3:12 am Post subject: Problem with Java class loaders and shared libraries |
 |
|
Novice
Joined: 04 Apr 2002
Posts: 23
|
We are getting mad with Java class loader issues:
- The messages flows are included in an application project. They include some JavaCompute nodes which associated Java classes are also located in the same application project.
- However, these Java classes (associated to the JavaCompute nodes) also use some utility classes included in JAR files located in a shared library.
At runtime, this does not work because the classes located in the shared library are loaded by a specific class loader.
Is there an option for asking that the shared libraries are executed using the integration node wide class loader, instead of a specific class loader? We did not find any.
Putting the utility JARs into the application projects is also not a good option, because that would make the BAR files of the application projects huge and the utility JARs would be duplicated.
Finally, is it a good idea to put Java classes into a shared library, since shared libraries are designed to share common code and, obviously, the Java classes can hardly be shared that way? |
|
| Back to top |
|
 |
| pmarie |
| Posted: Fri Jul 26, 2019 6:07 am Post subject: |
|
|
Novice
Joined: 04 Apr 2002
Posts: 23
|
We tried another way:
- We kept the JAR files in the shared library so that the Toolkit does not generate missing classes errors.
- We added all the JARs into the directory "/var/mqsi/config/<integration_node>/<integration_server>/shared-classes".
- We then tried to deploy the BAR file of the application project without the shared library (containing the JARs). This failed because the deployment function identified that the shared library was not deployed.
Therefore, this way did not work either. |
|
| Back to top |
|
|
| pmarie |
| Posted: Wed Jul 31, 2019 8:26 am Post subject: |
|
|
Novice
Joined: 04 Apr 2002
Posts: 23
|
The IIB lab recommended the following solution:
"Based upon your summary it sounds like the best solution would be to place their message flows inside applications which each refer to a shared library to hold their "specific" Java code ... and then in turn refer to another "common" shared library which contains their utility classes. This technique is discussed with some handy diagrams in this page of the Knowledge Center, which describes how to use the Java classloader service property with a qualifier to refer to the utility shared library in order to ensure that the preferred classloader is used:
https://www.ibm.com/support/knowledgecenter/en/SSMKHH_10.0.0/com.ibm.etools.mft.doc/bc23072_.htm
I think this should meet your requirement (you could separate the the message flow application and specific java inside a first shared library into one BAR file, and then the utility java in a second shared library in another BAR file)."
We tested this solution and it did work. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
