| Author |
Message
|
| avinandan9 |
 Posted: Fri Aug 05, 2011 3:27 am Post subject: Class name conflict |
 |
|
Newbie
Joined: 04 Aug 2011
Posts: 5
|
In my message flow, I use a JCN node that creates a CORBA Object.
The deployment environment is Unix.
I need to use a third party JAR for this , lets say the name of the JAR is ABC.JAR.
I have added this JAR file at location /var/mqsi/shared-classes
It contains package org.omg.CORBA and within it there is a class called ORB.class.
It contins the following method which is responsible for initializing the CORBA Object.
| Code: |
| public static ORB init(String[] paramArrayOfString, Properties paramProperties) |
When I deply my msg flow to the execution group and use the following code in the JCN
| Code: |
| org.omg.CORBA.ORB.init(args1, prop1); |
Whats happenening is that the broker runtime is referring to org.omg.CORBA.ORB.class in ibmorbapi.jar instead of the one I intend to use that is ABC.JAR.
The location of ibmorbapi.jar is /opt/IBM/mqsi/6.1/jre15/lib/
How to resolve this class name conflict ? Any help is welcome |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Aug 05, 2011 4:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
shared-classes is only loaded at EG startup.
So you likely didn't restart the EG. |
|
| Back to top |
|
|
| avinandan9 |
| Posted: Fri Aug 05, 2011 4:13 am Post subject: |
|
|
Newbie
Joined: 04 Aug 2011
Posts: 5
|
| mqjeff .. EG is restarted .. infact the BROKER is restarted once for this. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 05, 2011 4:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Then perhaps the permissions are wrong on the jar file in shared-classes.
Or your code is wrong somehow.
Take a startup trace of the Broker and look for statements about the classloading. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Aug 05, 2011 4:20 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
ibmorbapi.jar is IBM's implementation of same class you are trying to use. It will work exactly the same. No need to use the third party jar you have. It is a standards-compliant implementation.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| avinandan9 |
| Posted: Fri Aug 05, 2011 4:59 am Post subject: |
|
|
Newbie
Joined: 04 Aug 2011
Posts: 5
|
@ lancelotlinc The internal implementation of third party jar is different from that of ibmorbapi.jar
I have cross checked that. I need to use the third party jar here and not ibmorbapi.jar
@ mqjeff : The permission for jar files are set to rwx for the broker user. In terms of code issue am just trying to initialize the corba object by calling the init method so not much coding to make mistake here 
The trouble is that the ibmorbapi.jar is picked up by broker runtime and its initializing the default instance instead of the one which I need which is defined within the ORB.class in the third party jar
| Code: |
| private static final String defaultORB = "com.ibm.CORBA.iiop.ORB"; |
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 05, 2011 5:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Right.
A startup trace will SHOW YOU all of the steps taken to load the jar files from shared-classes and otherwise.
Or you can open a PMR. Which will result in you needing to run a startup trace so that they can review the classloading steps taken. |
|
| Back to top |
|
|
| visasimbu |
| Posted: Tue Aug 09, 2011 11:01 pm Post subject: |
|
|
Disciple
Joined: 06 Nov 2009
Posts: 171
|
Hi avinandan9,
Why not deploy the ABC.JAR in EG. By doing this, Broker will take the method (init) which is deployed in EG. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Aug 10, 2011 4:51 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| visasimbu wrote: |
Hi avinandan9,
Why not deploy the ABC.JAR in EG. By doing this, Broker will take the method (init) which is deployed in EG. |
Deploying jars to EG is not a best practice. And you have no guarantee which will load first, unless you clearly understand the class loading order and know that previous classes loaded did not load the other class first.
The reason this is not a best practice is, if you have several EGs and load the same jar in each, which verison is loaded where? If you update the version in one EG, the others will be out of date. Jars are system administration task to configuration management. For best results, in my opinion, refrain from deploying jars to EGs.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Wed Aug 10, 2011 5:46 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi
Sometimes deploying jars to execution groups can be perhaps acceptable.
If I'm remember correct for example in some environments it can be difficult to have maintenance break for whole production broker to install new (versions too) jars to shared_classes directory (broker loads them only at restart if I remember correct).
If you don't use continuous integration methods in your integration development it could be safer to deploy new versions of jars only to the EG's which flows are tested with new versions.
--
Marko |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Aug 10, 2011 6:12 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Hi Marko,
You raise a good point. I am suggesting that proper configuration management practice, where you have normal maintenance windows, is a preferred way to go.
Undoubtedly you will have some jars in your EGs (for example if you use JCNs in your flows). So it is possible that jars are in EGs.
In the discussion, third-party jars, like log4j, are better left in shared-classes. Not only is it impractical to manage at the EG level for versioning, it is also somewhat redundant. Take for example you have 20 EGs. Will you deploy log4j jar to each EG separately?
I wouldn't say its safer to deploy the log4j jar to each EG separately. Maybe easier on the developers. But then again, are you using good configuration management practices?
Lance
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 10, 2011 6:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It also depends on what version of Broker you're using.
In v7, you should use JavaClassloader configurable services in preference to shared-classes, unless you are really using jar files across the entire EG or broker. |
|
| Back to top |
|
|
|
|
