| Author |
Message
|
| MQMB&WAS |
 Posted: Tue Mar 27, 2018 5:40 am Post subject: purpose of .jar files |
 |
|
Centurion
Joined: 12 Jun 2016
Posts: 130
|
Hello team,
What is the reason application teams ask for .jar files? Are these files used as an alternate for the mq client component? If so, how are these files used and do they still need a ccdt or .binding file to connect to the remote qmgr?
Thanks for your time. |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Mar 27, 2018 5:54 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
If you mean the MQ .jar files, it's generally because the Applications people 'bundle' them into their package - rather than include them in CLASSPATH etc.
I believe that's not officially supported by IBM still, but in later versions IBM supplied 'relocatable' jars, and now provide 're-distributable' ones.
The problem with Apps bundling them is that they never get updated.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| MQMB&WAS |
| Posted: Tue Mar 27, 2018 6:06 am Post subject: |
|
|
Centurion
Joined: 12 Jun 2016
Posts: 130
|
| exerk wrote: |
If you mean the MQ .jar files, it's generally because the Applications people 'bundle' them into their package - rather than include them in CLASSPATH etc.
I believe that's not officially supported by IBM still, but in later versions IBM supplied 'relocatable' jars, and now provide 're-distributable' ones.
The problem with Apps bundling them is that they never get updated. |
Yes, I meant MQ .jars.
So, bundling these MQ .jars in applications .ears avoids the need of MQ Client component? And do they still need the ccdt or .bindings to make a connection to remote qmgr? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Mar 27, 2018 6:12 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| MQMB&WAS wrote: |
| ...And do they still need the ccdt or .bindings to make a connection to remote qmgr? |
Depends on how their application handles that - the site I'm on at the moment uses neither, but I'd prefer them to use a CCDT.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 27, 2018 6:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQMB&WAS wrote: |
| So, bundling these MQ .jars in applications .ears avoids the need of MQ Client component? |
You either need to make the jar files available to the application by installing the client, or by bundling the jars with the application. As my worthy associate points out, if the jars are bundled with the application experience teaches that they will never, ever, ever be updated and will become progressively back version to your queue manager.
| MQMB&WAS wrote: |
| And do they still need the ccdt or .bindings to make a connection to remote qmgr? |
Yes, because these components only contain the code needed to make a connection. They don't (and can't) contain the configuration information that says where the queue manager is. Do try and think this through.
If you're happy to have the jar files bundled with the application and remove the need for the MQ Client, then you can have the application supply the connection information as well and remove the need for a CCDT or bindings file as well.
That way not only will the application be stuck using the same level of MQ for it's client, it will be stuck using the same connection information. So not only can you break the application by upgrading the queue manager to a level the client doesn't support, you can break it by changing it's IP address.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Mar 27, 2018 6:48 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
...That way not only will the application be stuck using the same level of MQ for it's client, it will be stuck using the same connection information. So not only can you break the application by upgrading the queue manager to a level the client doesn't support, you can break it by changing it's IP address.
|
Are you looking over my shoulder? 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| MQMB&WAS |
| Posted: Tue Mar 27, 2018 6:53 am Post subject: |
|
|
Centurion
Joined: 12 Jun 2016
Posts: 130
|
| Thanks for clearing my doubts, exerk and Vitor. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 27, 2018 7:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| Vitor wrote: |
...That way not only will the application be stuck using the same level of MQ for it's client, it will be stuck using the same connection information. So not only can you break the application by upgrading the queue manager to a level the client doesn't support, you can break it by changing it's IP address.
|
Are you looking over my shoulder? |
It's not your shoulder....... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Mar 27, 2018 7:34 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| exerk wrote: |
| Vitor wrote: |
...That way not only will the application be stuck using the same level of MQ for it's client, it will be stuck using the same connection information. So not only can you break the application by upgrading the queue manager to a level the client doesn't support, you can break it by changing it's IP address.
|
Are you looking over my shoulder? |
It's not your shoulder....... |
I was only worried before, now I'm terrified! 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 27, 2018 8:04 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Ah, the joys of distributed apps.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 27, 2018 5:24 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 27, 2018 5:31 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
If you're happy to have the jar files bundled with the application and remove the need for the MQ Client, then you can have the application supply the connection information as well and remove the need for a CCDT or bindings file as well.
That way not only will the application be stuck using the same level of MQ for it's client, it will be stuck using the same connection information. So not only can you break the application by upgrading the queue manager to a level the client doesn't support, you can break it by changing it's IP address.
|
Because every time we upgrade an MQ server, we upgrade all the MQ Clients, just not the ones that bundled the jars, right? Rrrriiiight.
If some company has an MQ team with the resources to install MQ Client on every app server and patch every install of client as they patch the MQ servers, I'd be amazed. And jealous.
Back in the real world I'd rather show the apps how they can get the jars, how they can include them with their app, in their app or alongside their app (IBM offers several ways now), and most importantly show them how they can be initially "installed" and maintained going forward without someone with root or Administrator rights, and especially without it being an MQ Admin. Its not too much to ask the app to have some accountability in the currency of their software. I said ask, not expect.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 28, 2018 5:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| If some company has an MQ team with the resources to install MQ Client on every app server and patch every install of client as they patch the MQ servers, I'd be amazed. And jealous. |
The miracle of automation.
Getting all the app teams to regression test their existing apps with the new clients is like herding cats as it is. Getting them to actually "change" their applications by putting new jars in and do a full retest is something I'm too old to consider.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 28, 2018 8:23 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Vitor wrote: |
| ... herding cats ... |
I used this expression at a client quite some time ago. I was promptly attacked by a sysadmin who thought she heard me say "hurting cats," which is an entirely different subject.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Mar 28, 2018 7:04 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
| PeterPotkay wrote: |
| If some company has an MQ team with the resources to install MQ Client on every app server and patch every install of client as they patch the MQ servers, I'd be amazed. And jealous. |
The miracle of automation.
|
Touche
It is less a technical challenge and more a people/process/politics problem.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
