My idea of Jar-Hell :( Just like DLL's/SharedObject's Hell.
--- James M Snell <jasnell@us.ibm.com> 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
> jasnell@us.ibm.com
> (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
>
>
>
> Kevin.Bedell@sunlife.com
> 01/06/2003 05:54 PM
> Please respond to axis-dev
>
>
> To
> axis-dev@xml.apache.org
> cc
> "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
> 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: "'axis-dev@xml.apache.org'"
> <axis-dev@xml.apache.org>
> <gdaniels@macromedia.com> 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: Kevin.Bedell@sunlife.com [mailto:Kevin.Bedell@sunlife.com]
> > Sent: Monday, January 06, 2003 3:31 PM
> > To: axis-dev@xml.apache.org
> > Cc: 'axis-dev@xml.apache.org'
> > 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:
> > "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
> >
> > <gdaniels@macromedia.com> 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:jmeritt@sonicsoftware.com]
> > > Sent: Monday, January 06, 2003 3:24 PM
> > > To: axis-dev@xml.apache.org
> > > 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
|