| Author |
Message
|
| belchman |
 Posted: Thu Aug 27, 2015 4:50 am Post subject: Use MQv7 Jar files after MQv7 OOS? |
 |
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
To set up the question, let me explain my current situation.
In our world we have these WebSphere Application Server (WAS) cells that have many nodes contained within that have many different applications spread across those nodes. Not every application os on every node but all of the nodes are managed by the one deployment manager.
This WAS node sits on an AIX system.
To further complicate things, we also have other cells, that may or may not be the same WAS version, that have cells that sit on AIX hosts that also support the aforementioned cell.
Regarding WebSphere MQ (WMQ), some of the AIX hosts also host WMQ and some of the applications on both cells consume the WMQ services. Some connect in bindings mode and some connect in client mode.
We are currently racing to the finish line on our Enterprise upgrade from WMQv7 to WMQv8 for obvious reasons.
So that is the world that generates my following "request for input".
One of the apps on one of the cells, consumes the services of WAS v8.0, WMQv8.0 and AIXv6.1. That app is COTS and it is not certified on WQMv7.5 nor WMQv8.0.
Tests have proven that the app must have the MQv7 java libraries. The app throws a Major Version Mismatch error in java if we point it to the MQv8 libaries.
To resolve this, my preferred plan is to keep the MQv7 libraries on the AIX host and point the cells hosting the app to the MQv7 libraries (that seem to operate without issue against the MQv8 queue manager). So on any relevant AIX host, there will be MQv7 and MQv8 copies of .../mqm/java/lib(and 64).
This solution is only a stopgap until the application can upgrade to a version that does not require MQv7 libraries.
Can you please do your best to explain "how wrong I am" or "how right I am" in my thinking?
Thanks
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
 |
| belchman |
| Posted: Thu Aug 27, 2015 4:53 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
It always happens that I forget something.
As my test, I simply TARed and moved /usr/mqm/java to a new spot to mimic an MQv7 cleint install to create the new v7 classes location. I assume that their is no difference between MQ server and MQ client installs with ragards to the contents of .../java
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 27, 2015 8:50 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
There is however.
To use MQ8 java libraries you need a minimum of java V7 as described in the documentation. In fact a version of Java comes with the (full) client.
Now I suspect that when you got your version mismatch you were running Java V1.6...
You need to verify for which version of java your application is certified, what the effort would be to certify it at a higher version of java and go from there. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| belchman |
| Posted: Mon Aug 31, 2015 4:29 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Let me start off by clarifying this
| Quote: |
| I assume that their is no difference between MQ server and MQ client installs with regards to the contents of .../java |
I mean that I assume the contents of ../java is the same regardless of if it was generated via an MQ server install or an MQ client install.
Now regarding
| Quote: |
| To use MQ8 java libraries you need a minimum of java V7 as described in the documentation |
I am aware of this. I assume the issue is because the app has some classes that are compiled with a java version too old to work with MQv8 libraries but work OK with MQv7 libraries. The version mismatch is raised only when WAS is pointing to the MQv8 libraries. When pointing to MQv7 libraries the error is not raised.
So on this particular AIX host, I have both /usr/mqm/7.0/java and /usr/mqm/8.0/java directories. Most WAS JVMs have the v8 classpath and this one has the v7 classpath. BUT, the queue manager in all instances is MQv8.
The burning question I have right now, so I can possibly not worry about getting MQ client installed (which is not trivial) is
| Quote: |
| Are the contents of /usr/mqm/java is the same that would have been installed with an MQ client install of the same version? |
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Aug 31, 2015 9:09 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| belchman wrote: |
Let me start off by clarifying this
| Quote: |
| I assume that their is no difference between MQ server and MQ client installs with regards to the contents of .../java |
I mean that I assume the contents of ../java is the same regardless of if it was generated via an MQ server install or an MQ client install. |
Not quite. You'd only have the client exits as dlls / so files in the client install...
| belchman wrote: |
Now regarding
| Quote: |
| To use MQ8 java libraries you need a minimum of java V7 as described in the documentation |
I am aware of this. I assume the issue is because the app has some classes that are compiled with a java version too old to work with MQv8 libraries but work OK with MQv7 libraries. The version mismatch is raised only when WAS is pointing to the MQv8 libraries. When pointing to MQv7 libraries the error is not raised.
So on this particular AIX host, I have both /usr/mqm/7.0/java and /usr/mqm/8.0/java directories. Most WAS JVMs have the v8 classpath and this one has the v7 classpath. BUT, the queue manager in all instances is MQv8.
The burning question I have right now, so I can possibly not worry about getting MQ client installed (which is not trivial) is
| Quote: |
| Are the contents of /usr/mqm/java is the same that would have been installed with an MQ client install of the same version? |
|
No, the more recent versions of MQ don't have exactly the same jar file names and the classes inside the jar files may have moved from one jar to the other...
If you're asking if you can copy the /usr/mqm/java/lib directory the answer is : it is not recommended. It might get you out of your plight but could introduce side effects (think get with translate etc...).
Look at MQ V8 and there is a "distributable" with name com.ibm.mq.allclient.jar this can be used with your application without the full client (see documentation). However AFAIK for lower versions of MQ you are still recommended to have the full client.
Hope it helps
_________________
MQ & Broker admin
Last edited by fjb_saper on Mon Aug 31, 2015 9:15 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 31, 2015 9:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The client install from the server media and the client install from the client media for the same version and FP level of MQ will be identical.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Aug 31, 2015 9:20 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
| The client install from the server media and the client install from the client media for the same version and FP level of MQ will be identical. |
| belchman wrote: |
| The burning question I have right now, so I can possibly not worry about getting MQ client installed (which is not trivial) is |
The purpose of the OP was to not install the client, but only the java libs.
While this might work it is only supported in V8 with the com.ibm.mq.allclient.jar
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| belchman |
| Posted: Mon Aug 31, 2015 9:33 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Thanks MQJeff and fjp_saper. I am looking into what you are saying and will get back to you.
Keep in mind, this is a stop-gap solution until the app can upgrade.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| belchman |
| Posted: Tue Sep 01, 2015 10:03 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Straight from an ESR I opened with IBM:
| Quote: |
| if you have only WAS 8.0 and WebSphere MQ 8.0 installed on the same machine you cannot use bindings mode |
but the workaround I point out above will likely work but is not supported
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| tomleend |
| Posted: Tue Sep 01, 2015 10:24 am Post subject: |
|
|
Acolyte
Joined: 24 Jan 2014
Posts: 51
|
belchman,
There is no need for you to use an external copy of the WMQ Java client jar files when running applications that connect to an MQ queue manager within WebSphere Application Server (WSAS) v7.0 or later. From WSAS v7.0 you must use the WebSphere MQ JCA Resource Adapter, which is the component within WSAS that handles all of the communication to WMQ queue managers.
For reference, WSAS v7 and v8.0 ship the WMQ v7.0.1 RA whereas WSAS v8.5 ships the WMQ v7.1 RA. Support for the WMQ RA code is entitled through WSAS.
When connecting using the BINDINGS transport mode, you only need to configure the WMQ Resource Adapter's native library path to point to the WebSphere MQ server install directory where the native "mqjbnd" JNI library is installed. The level of the native library you should use should match that of the highest version of queue manager to which WSAS connects. |
|
| Back to top |
|
|
| belchman |
| Posted: Tue Sep 01, 2015 10:34 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
tomleend,
According to IBM (in an ESR I opened), unless I misread their words, the Java1.6 system under WASv8 will throw a 'version mismatch' error when it tries to use the MQv8 java classes that were compiled with java v1.7.
These classes are used when you try to connect to MQ from WAS in bindings mode.
My tests support IBMs statement. If I point WAS to the MQv8 libraries, I get the version mismatch error. If I point to the MQv7 libraries (that support java v1.4.2, 1.5 and 1.6, I do not get the error.
Are you actually connecting WASv8 to a WMQv8 queue manager in bindings mode?
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| belchman |
| Posted: Tue Sep 01, 2015 10:38 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Just so all know, I am assuming that setting MQ_INSTALL_ROOT to MQPath and setting libpath on the resource adapter to MQPath is effectively the same thing.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| tomleend |
| Posted: Tue Sep 01, 2015 11:58 am Post subject: |
|
|
Acolyte
Joined: 24 Jan 2014
Posts: 51
|
Hi belchman,
| Quote: |
| java1.6 system under WASv8 will throw a 'version mismatch' error when it tries to use the MQv8 java classes that were compiled with java v1.7. |
This is correct but it does not matter here.
You only need to use WMQ JCA Resource Adapter (RA) shipped within WSAS and the native bindings library from the MQ server install to connect in BINDINGS mode, as I mentioned previously. You must not use any MQ java client jar files that are external to WSAS itself. The only external library you require is the native JNI library "mqjbnd".
So, to make a BINDINGS transport mode connection from WSAS, you only need to go to the Resource Adapter definitions and update the native library path configuration. In the WSAS admin console, the breadcrumb trail is:
Resources --> Resource Adapters --> Resource adapters --> Choose preferences and select "Show built-in resources", then choose the WebSphere MQ Resource Adapter form the list to configure the native library path for.
(FYI, this is the preferred mechanism over the MQ_INSTALL_ROOT WSAS environment variable so I would suggest trying this).
When configuring like this, I can successfully make a BINDINGS transport mode connection from WSAS v8 and WSAS v8.5 to an MQ v8 queue manager and drive an MDB application.
Hope this helps! |
|
| Back to top |
|
|
| belchman |
| Posted: Tue Sep 01, 2015 2:30 pm Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
tomleend,
I will test that out tomorrow and get back to this board with the results.
Thx for the feedback
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
|
|
