My idea of Jar-Hell :( Just like DLL's/SharedObject's Hell. --- James M Snell <[EMAIL PROTECTED]> wrote: > Btw, I personally think that individual Axis transports should be put into > their own jar files (e.g. axis-jms.jar, axis-local.jar, axis-http.jar, > etc) so if a particular application doesn't need a particular transport it > can simply remove the jar file altogether. But that's just my opinion > > - James Snell > IBM Emerging Technologies > [EMAIL PROTECTED] > (559) 587-1233 (office) > (700) 544-9035 (t/l) > Programming Web Services With SOAP > O'Reilly & Associates, ISBN 0596000952 > > Have I not commanded you? Be strong and courageous. > Do not be terrified, do not be discouraged, for the Lord your > God will be with you whereever you go. - Joshua 1:9 > > > > [EMAIL PROTECTED] > 01/06/2003 05:54 PM > Please respond to axis-dev > > > To > [EMAIL PROTECTED] > cc > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > bcc > > Subject > RE: JMS transport not in 1.1 binary distribution > > > > > > <Just Kevin's Opinion> > > The ideal solution would be for me as a user to simply specify the > transport/adapter in the wsdd file and make sure weblogic.jar (or > jboss.jar, or whatever) is on the classpath. The developer of the > transport > implementation would assume I've got the appropriate third-party classes > on > my classpath. > > If I specify a transport implementation that I don't have the libs for > then > I would get ClassNotFound or some other error when I tried to use it. > > The transport interface classes would be in axis.jar (or some other > axis-supplied jar maybe similar to the 'optional.jar' that Ant supplies) - > but not something I have to build. > > The Ant "optional.jar" seems like a good model - they have all kinds of > third-party interface code in there. The advantage of a single jar is both > you have to download fewer files and the configuration is easier to manage > over time. > > </Just Kevin's Opinion> > > > > > > > > > Glen Daniels To: "'[EMAIL PROTECTED]'" > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> cc: (bcc: Kevin > Bedell/Systems/USHO/SunLife) > 01/06/2003 03:39 PM Subject: RE: JMS transport not in 1.1 > binary distribution > Please respond to axis-dev > > > > > > > > Well, I agree with you. I don't think you should need to build from > source > to use third-party stuff. But nor do I think we should have any in > axis.jar. > > I haven't really looked at the JMS transport stuff yet, but I'm assuming > that there's just a setting (engine property / system property /etc) which > determines the actual vendor-JMS-interface class to use. So you should > just be able to pull down a separate sonic-axis-transport.jar (or > something), drop that in your classpath, and set the property in your > server-config.wsddd/client-config.wsdd. > > Jaime / Dave, is that about how it works? If so, we just need an > axis/dist/third-party directory so people can pick up the custom jars for > stuff like this. > > --Glen > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Monday, January 06, 2003 3:31 PM > > To: [EMAIL PROTECTED] > > Cc: '[EMAIL PROTECTED]' > > Subject: RE: JMS transport not in 1.1 binary distribution > > > > > > > > > > So out of the box Axis can't be used with any specific JMS > > implementations? > > This seems like it would impede adoption. > > > > If I have to build from source, does that mean using a > > nightly build? For > > many of us working in the stodgy, old financial services industry that > > means we won't be able to use it - using nightly build stuff > > in production > > is frowned on. > > > > As a user, I'd prefer that I could download and use something > > out of the > > box - assuming I have the third party jars I need already. > > > > For example, I've got weblogic here and am using Weblogic JMS > > for other > > apps. If there were a JMS adapter for weblogic, I'd prefer to > > use it out of > > the box and just make sure the weblogic JMS classes were on > > the classpath. > > Ideally, there would be 'stable builds' that would contain > > the classes I > > needed already compiled. > > > > Does that make sense? > > > > > > > > > > > > > > > > > > > > Glen Daniels To: > > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > > > <[EMAIL PROTECTED]> cc: (bcc: > > Kevin Bedell/Systems/USHO/SunLife) > > > > 01/06/2003 03:25 PM Subject: RE: > > JMS transport not in 1.1 binary distribution > > > > Please respond to axis-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > Correct. Generic JMS stuff is OK to have in the JAR, but any > > vendor-specific stuff like Sonic/IBM/etc is not, at least as > > far as I'm > > concerned. Other opinions? > > > > --Glen > > > > > -----Original Message----- > > > From: Jaime Meritt [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, January 06, 2003 3:24 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: JMS transport not in 1.1 binary distribution > > > > > > > > > Glen, > > > > > > Great, thanks a lot for the help. To get the > > SonicMQVendorAdapter to > > > build you will need the SonicMQ client jars available as > > > well. What is > > > the current policy on third party library dependencies? Does > > > the binary > > > distribution include all options or just the default > > packages? If it > > > includes all options, I can send you Sonic client libraries > > for build > > > purposes. If not, I am assuming the solution is to have users build > > > from the source distribution. > > > > > > Thanks, > > > Jaime > > > > === message truncated ===
===== Davanum Srinivas - http://xml.apache.org/~dims/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
