| Author | Message | 
		
		  | 70033 | 
			  
				|  Posted: Fri Sep 10, 2010 6:42 am    Post subject: JMS with IBMMQ jar dependencies during run time |   |  | 
		
		  | Apprentice
 
 
 Joined: 22 Dec 2008Posts: 27
 
 
 | 
			  
				| Hi , 
 If I just use the Apache standard way to communicate with just JMS standard code from this link.
 http://wiki.apache.org/tomcat/HowTo#How_do_I_connect_to_a_Websphere_MQ_.28MQ_Series.29_server_using_JMS_and_JNDI.3F
 I am still forced to use the MQ libraries during runtime which i would like to avoid. Currently we are putting messages onto the IBM MQ but i would like to not even have MQ libraries in my classpath when running . How do i do this, so that if i want to switch over to other providers , I just need to reconfigure ..
 
 Also, I would like to use OpenJMS client to communicate with IBMMQ providers. Has anyone tried this? If so do you still require MQ libraries in the classpath when running?
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | Vitor | 
			  
				|  Posted: Fri Sep 10, 2010 6:59 am    Post subject: Re: JMS with IBMMQ jar dependencies during run time |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 11 Nov 2005Posts: 26093
 Location: Texas, USA
 
 | 
			  
				| 
   
	| 70033 wrote: |  
	| I am still forced to use the MQ libraries during runtime which i would like to avoid. Currently we are putting messages onto the IBM MQ but i would like to not even have MQ libraries in my classpath when running . How do i do this, so that if i want to switch over to other providers , I just need to reconfigure .. |  
 Ok, I should know better than to attempt a Java question but it's Friday & I'm feeling lucky & I speak a little Tomcat.....
   
 On the understanding that my Java is weak & more administrative than coding, I don't quite understand what you're getting at. Your code is pure JMS & therefore provider neutral. I got that. You're trying to minimise the number of changes needed if you change JMS providers. I got that.
 
 AFAIK the point of having the provider information in context.xml is that you only need to change that one file. If you switched to ActiveMQ (for instance) you'd still need to edit the connection details and (I imagine) change type & factory to their values.
 
 At some point somewhere, you need to reference the actual JMS & database you're using. Don't you? Am I missing the point? Isn't the point that the code doesn't need changing?
 
 Ok, it's a Java query put I'm still pushing submit.....
 _________________
 Honesty is the best policy.
 Insanity is the best defence.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | 70033 | 
			  
				|  Posted: Fri Sep 10, 2010 7:05 am    Post subject: Runtime dependencies |   |  | 
		
		  | Apprentice
 
 
 Joined: 22 Dec 2008Posts: 27
 
 
 | 
			  
				| I agree that i need to change my configuration and that is required . However now i need to also add the provider specific jars in the tomcat libs so that at runtime I use them . 
 So say for eg. I dont want to install MQclient in my box but i still want to post JMS Messages to a MQ from tomcat , how do I do that (if i can)..
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | Vitor | 
			  
				|  Posted: Fri Sep 10, 2010 7:07 am    Post subject: Re: Runtime dependencies |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 11 Nov 2005Posts: 26093
 Location: Texas, USA
 
 | 
			  
				| 
   
	| 70033 wrote: |  
	| So say for eg. I dont want to install MQclient in my box but i still want to post JMS Messages to a MQ from tomcat , how do I do that (if i can).. |  
 You use whatever dark Java magic you'd normally employ to access jar files that are not on your box. Ask yourself what you'd do if you wanted to put a message to ActiveMQ but didn't want to put their provider specific jars on your box, then do that.
 
 In my experience (and please remember Java's not my thing) the jar files for WMQ / DB2 / Oracle / etc / etc have all been local.
 _________________
 Honesty is the best policy.
 Insanity is the best defence.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | fjb_saper | 
			  
				|  Posted: Fri Sep 10, 2010 7:11 am    Post subject: Re: Runtime dependencies |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 18 Nov 2003Posts: 20767
 Location: LI,NY
 
 | 
			  
				| 
   
	| 70033 wrote: |  
	| I agree that i need to change my configuration and that is required . However now i need to also add the provider specific jars in the tomcat libs so that at runtime I use them . 
 So say for eg. I dont want to install MQclient in my box but i still want to post JMS Messages to a MQ from tomcat , how do I do that (if i can)..
 |  And how pray are you going to use a DB or Messaging provider without having the corresponding implementation jars on the classpath?
 
 The whole point here is if you change provider, all you need to change is the JNDI and the classpath. The application does not change.
 
 Like for a database, when you switch from MSSQL to Oracle, you still need the corresponding class 4 driver on the path, or in a loadable location, for the JNDI/runtime setup.
 
 
 Have fun
  _________________
 MQ & Broker admin
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | 70033 | 
			  
				|  Posted: Fri Sep 10, 2010 7:13 am    Post subject: Runtime jars |   |  | 
		
		  | Apprentice
 
 
 Joined: 22 Dec 2008Posts: 27
 
 
 | 
			  
				| But the question I have is do we need to have the provider specific jars or is there any provider agnostic implementation with which i can communicate to MQ today but any non-MQ provider tomorrow.. |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | Vitor | 
			  
				|  Posted: Fri Sep 10, 2010 7:14 am    Post subject: Re: Runtime dependencies |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 11 Nov 2005Posts: 26093
 Location: Texas, USA
 
 | 
			  
				| 
   
	| fjb_saper wrote: |  
	| The whole point here is if you change provider, all you need to change is the JNDI and the classpath. The application does not change. |  
 Yay me! I got a Java query virtually right!
         
 
  _________________
 Honesty is the best policy.
 Insanity is the best defence.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | 70033 | 
			  
				|  Posted: Fri Sep 10, 2010 7:19 am    Post subject: |   |  | 
		
		  | Apprentice
 
 
 Joined: 22 Dec 2008Posts: 27
 
 
 | 
			  
				| Ok thanx to both of you guys.. Thats what i thought but i want to confirm b4 blurting to the big dogs  |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | fjb_saper | 
			  
				|  Posted: Fri Sep 10, 2010 7:21 am    Post subject: Re: Runtime jars |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 18 Nov 2003Posts: 20767
 Location: LI,NY
 
 | 
			  
				| 
   
	| 70033 wrote: |  
	| But the question I have is do we need to have the provider specific jars or is there any provider agnostic implementation with which i can communicate to MQ today but any non-MQ provider tomorrow.. |  
 There is no provider agnostic implementation for the service. There is only an agnostic interface to the service implementation. And as you know an interface does not work without implementing classes, and those are inside the provider specific jars.
 
 So forget your pipe dream. You DO NEED the provider jars on the classpath!
  _________________
 MQ & Broker admin
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | 70033 | 
			  
				|  Posted: Fri Sep 10, 2010 7:33 am    Post subject: OpenJMS anyone.. |   |  | 
		
		  | Apprentice
 
 
 Joined: 22 Dec 2008Posts: 27
 
 
 | 
			  
				| If i were to use OpenJMS to connect to IBMMQ , would i still need the MQ jars (Please say Yes and dont throw stuff at me  ) during runtime ..  Thats the last question i promise.. |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | Vitor | 
			  
				|  Posted: Fri Sep 10, 2010 7:38 am    Post subject: Re: OpenJMS anyone.. |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 11 Nov 2005Posts: 26093
 Location: Texas, USA
 
 | 
			  
				| 
   
	| 70033 wrote: |  
	| If i were to use OpenJMS to connect to IBMMQ , would i still need the MQ jars |  
 If you were to use OpenJMS to connect to ActiveMQ, would you still need the ActiveMQ jars?
 _________________
 Honesty is the best policy.
 Insanity is the best defence.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | Vitor | 
			  
				|  Posted: Fri Sep 10, 2010 7:49 am    Post subject: Re: OpenJMS anyone.. |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 11 Nov 2005Posts: 26093
 Location: Texas, USA
 
 | 
			  
				| 
   
	| 70033 wrote: |  
	| If i were to use OpenJMS to connect to IBMMQ , would i still need the MQ jars |  
 Here's a question for you; if you didn't need the MQ jars would it be worth doing? You've eliminated the need for jar files on your box, and we'll assume that the OpenJMS server is on a different box (which I think is impossible). So your MDB runs under Tomcat, which connects to OpenJMS, which connects to WMQ using the MQ jars (because at some point something needs to understand the provider). If you get all that working, what happens when you need to troubleshoot? Or apply maintenance?
 
 What happens if your MDB uses a database? Will you indirect the JDBC connection is the same way? How much will all this network cost your app in performance?
 
 Or do you just install the clients locally and make your life that much simpler?
 
 One final question for you; why not install the jars locally? What brought this up? Some weird management desire for a mythically vendor neutral solution or a real requirement?
 _________________
 Honesty is the best policy.
 Insanity is the best defence.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | mqjeff | 
			  
				|  Posted: Fri Sep 10, 2010 7:58 am    Post subject: Re: OpenJMS anyone.. |   |  | 
		
		  | Grand Master
 
 
 Joined: 25 Jun 2008Posts: 17447
 
 
 | 
			  
				| 
   
	| 70033 wrote: |  
	| If i were to use OpenJMS to connect to IBMMQ , would i still need the MQ jars (Please say Yes and dont throw stuff at me  ) during runtime ..  Thats the last question i promise.. |  
 Let's be a little more straightfoward about the answer you've already been given to this question.
 
 Any use of JMS at all REQUIRES Provider Specific Jars.
 
 JMS itself is a Provider-Neutral technology that isolates your application from Provider Specific logic.  But it still requires Provider Specific implementation logic on the class path.
 
 ALL JMS implementations require Provider Specific Jars to allow you to write Provider-Neutral applications.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | 70033 | 
			  
				|  Posted: Fri Sep 10, 2010 7:59 am    Post subject: |   |  | 
		
		  | Apprentice
 
 
 Joined: 22 Dec 2008Posts: 27
 
 
 | 
			  
				| This might be my ignorance on the OpenJMS product but i was thinking of just using the OpenJMS client to connect to different providers like MQ,TIBCO,etc . I wasnt planning to get OpenJMS server at all. Now I dont know how closely tied they are and whether the OpenJMS client libraries are totally provider agnostic, which is probably just a myth  and can connect to MQ, "X" Queue provider,etc 
 This is of course the management desire to have a vendor neutral solution just by changing configuration ( and not adding any provider specific jars anywhere).
 
 Now if copying provider specific jars to the appropriate directory is the only way to do then we will go with that solution. So thanx for all your help..
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | Vitor | 
			  
				|  Posted: Fri Sep 10, 2010 8:12 am    Post subject: |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 11 Nov 2005Posts: 26093
 Location: Texas, USA
 
 | 
			  
				| 
   
	| 70033 wrote: |  
	| This is of course the management desire to have a vendor neutral solution just by changing configuration ( and not adding any provider specific jars anywhere). |  
 I knew it! I just knew it! I'm on fire today.....
       
 Of course, you could reasonably argue that that's exactly what you've achieved. To change vendors you just change the configuration, which includes installing the vendor specific components. You don't need to change or regression test a line of code.
 _________________
 Honesty is the best policy.
 Insanity is the best defence.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  |  |