No offense taken Tom :-) I fully expected to distribute the Jabber
transport as a separate jar. IMHO, The main Axis jar should contain only
the core and most common functionality.
- 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
Tom Jordahl <[EMAIL PROTECTED]>
01/08/2003 07:35 AM
Please respond to axis-dev
To
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc
bcc
Subject
RE: JMS transport not in 1.1 binary distribution
I agree with Dims, I don't think we want to get to far down the DLL/Jar
Hell road by breaking things up in to LOTS of jar files. We already have
saaj.jar and jaxrpc.jar, which is bad enough, not to mention the commons
stuff....
That being said, for JMS and Jabber transports I would support having in
their own jar files, because I don't think they will be main stream enough
for general use.
(Nothing personal James!)
--
Tom Jordahl
Macromedia Server Development
-----Original Message-----
From: Steve Loughran [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 07, 2003 8:46 PM
To: [EMAIL PROTECTED]
Subject: Re: JMS transport not in 1.1 binary distribution
----- Original Message -----
From: "James M Snell" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 06, 2003 21:11
Subject: RE: JMS transport not in 1.1 binary distribution
> 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
+1.
IMO we could generic this with a general 'axis extension jar'; have a
descriptor that lists classes that implement some optional plugin
interface
that get autocalled on plug in as AxisEngine boots up. This would be
useful
for handlers, transports and other things.
Speaking of extensions, say I had something I was looking to commit that
was
definately an axis extension. Where should it go in CVS. I propose a new
/extensions subdir for these things, which are not proposals but not core
codebase either.
-steve
