axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Jordahl" <tjord...@adobe.com>
Subject RE: [Axis2] Understanding Axis2 dependencies
Date Tue, 23 Oct 2007 18:30:24 GMT
Of course if Axis2 switched to commons-logging 1.1 and the container it
is running in uses 1.0.4 (for instance) then you are worse off than when
you started.

My feeling is that commons-logging is a great idea - as long as you are
the only one in the "pool" using it.  Once you try to integrate with
another J2EE server/project/whatever that *also* uses it, you tend to
get in to trouble.

Using the JDK api just gets Axis2 out of the line of fire in the
"logging wars".
--
Tom Jordahl

-----Original Message-----
From: robert lazarski [mailto:robertlazarski@gmail.com] 
Sent: Monday, October 22, 2007 8:01 PM
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] Understanding Axis2 dependencies

I've been stuck in classloader hell many times and moving to
commons-logging 1.1 solved a lot of problems for me - there's been a
lot of work put into that area. Also, everything else in apache land
uses commons-logging. +1 for keeping it.

Robert

On 10/22/07, Tom Jordahl <tjordahl@adobe.com> wrote:
> [Concerning commons-logging]
> > also what would you replace it with ?
>
> I actually think that the JDK 1.4 logging APIs would probably do the
> trick, not have "jar hell" problems, and be functional enough for most
> everyone.
>
> --
> Tom Jordahl
>
> -----Original Message-----
> From: Ajith Ranabahu [mailto:ajith.ranabahu@gmail.com]
> Sent: Wednesday, October 17, 2007 10:39 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [Axis2] Understanding Axis2 dependencies
>
> Hi,
>
> On 10/17/07, Eran Chinthaka <chinthaka@opensource.lk> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Since the topic is about jar dependencies, I'd like to comment on
two
> > aspects.
> >
> > 1. As one can see there is a huge number of dependencies we have in
> > Axis2 and I think we ship almost all of them with our releases. Why
> > should we release both xbeans and jibx with adb? My suggestion,
let's
> > ship the minimum number of jars required for a user. If he needs to
> use
> > XmlBeans, then let him download it. Same thing for JiBX.
> > And also it is better to see the minimum set of jars required to run
a
> > client somewhere. I raised this point couple of days before also. If
> you
> > need to do a SOAP call, you need to include more than 20-25 jars.
>
> Yes we can do that. We already pick up the databinding implementation
> by reflection and it is easy enough to print a message to print a
> readable error message for the absence of the jars.
> What I prefer to have is jar bundles for each databinding. Say for
> XMLBeans we have a xmlbeans bundle (Xbeans jar, the Xbeans-codegen
> module etc) and so on.
>
> > 2. Why do we need to have commons-logging? One would say well it
let's
> > you plug "any" logging module. How many of the users have really
used
> a
> > logging framework other than log4j? This is YAGNI for me. (you can
> also
> > see very good comments about commons-logging from our valuable
admirer
> > here http://www.bileblog.org/?p=259)
>
> Well not really. All our logging code is based on commons-logging. If
> we are to remove this code it would be somewhat significant effort and
> also what would you replace it with ? The way it is right now is the
> best way. What we can do is to send the default config to use
> java.util logging so that we do not need to send the log4j jar along.
>
>
> >
> > Just my 2 cents.
> >
> > Thanks,
> > Chinthaka
> >
> > Sanka Samaranayke wrote:
> > > Hi,
> > >
> > >
> > >
> > >
> > > Sanjiva Weerawarana wrote:
> > >> Thanks Ajith.
> > >>
> > >> I think we should document this somewhere- we often get this
> question
> > >> and there's obviously reasons for why we have all these
> dependencies.
> > >> We need to clearly indicate which things are optional and
indicate
> > >> under what conditions they come into use.
> > >>
> > >> I am not a fan of going back to the seven different distributions
> > >> model as that was confusing to users. Knowing the dependency
> reasons
> > >> will help embedders decide what they really need to pull in and
> what's
> > >> optional.
> > >>
> > >> One jar I didn't understand is the mex jar. Why is that around;
> that
> > >> should only be in the mex mar I believe.
> > >
> > > You need that jar if you use MexClient in your client code.
> > >
> > > Thanks,
> > > Sanka
> > >
> > >>
> > >>
> > >> Sanjiva.
> > >>
> > >> Ajith Ranabahu wrote:
> > >>> Hi Lawrence,
> > >>> Let me see whether I can make sense of some of the stuff. Others
> will
> > >>> chip in as needed and will surely holler if I make a mistake.
> > >>>
> > >>>> Axis2 Third Party Dependencies
> > >>>> ------------------------------
> > >>>> activation-1.1.jar                    MIME support
> > >>>> annogen-0.1.0.jar                     Annotation support
> > >>>> axiom-api-1.2.5.jar                   XML pull parsing
> > >>>> axiom-dom-1.2.5.jar                   XML pull parsing
> > >>>> axiom-impl-1.2.5.jar                  XML pull parsing
> > >>>> backport-util-concurrent-2.2.jar      ?
> > >>>
> > >>> Thread pooling support. This feature is built in for Java 1.5
and
> this
> > >>> particular jar has a backport of that code to Java 1.4
> > >>>
> > >>>> commons-codec-1.3.jar                 URL encoding?
> > >>>> commons-fileupload-1.1.1.jar          Used for uploading new
> service
> > >>>>                                       files in the admin
client?
> > >>>
> > >>> Yes - needed only when using the webapp
> > >>>
> > >>>> commons-httpclient-3.0.1.jar          Used by the Axis2 kernel?
> > >>>
> > >>> Yes - but primarily on the client side. I believe it is needed
in
> the
> > >>> server side if asynchronous calls are to be supported.
> > >>>
> > >>>> commons-io-1.2.jar                    ?
> > >>>> commons-logging-1.1.jar               Is this related to Log4J?
> > >>>
> > >>> Well kind of. Commons logging is a common API on multiple
logging
> > >>> frameworks (log4j/java.util.logging) but allows the switching of
> the
> > >>> logging engine easily. All the logging code inside the Axis2
> source
> > >>> are made using commons logging classes.
> > >>>
> > >>>> geronimo-annotation_1.0_spec-1.1.jar  More annotation support?
> > >>>> geronimo-jms_1.1_spec-1.1.jar         JMS bindings?
> > >>>
> > >>> JMS transport really.
> > >>>
> > >>>> httpcore-4.0-alpha5.jar               Used by the Axis2 kernel?
> > >>>> httpcore-nio-4.0-alpha5.jar           Used by the Axis2 kernel?
> > >>>> httpcore-niossl-4.0-alpha5.jar        Used by the Axis2 kernel?
> > >>>
> > >>> The nio (non-blocking io) transport dependancies. Its an
improved
> > >>> version of the HTTP transport. My understanding is that this is
> used
> > >>> optionally (the default Axis2.xml does not point to this
transport
> > >>> AFAIK) but needs confirmation
> > >>>
> > >>>> jaxb-api-2.0.jar                      Used by the Axis2 kernel?
> > >>>> jaxb-impl-2.0.5.jar                   Used by the Axis2 kernel?
> > >>>> jaxb-xjc-2.0.5.jar                    Used by the Axis2 kernel?
> > >>>
> > >>> These were primarily for the Jaxb based code generation but now
> the
> > >>> JAX-WS module uses these as dependencies. In any case these are
> needed
> > >>>  1. if the user needs to generate code with Jaxb data binding
> > >>>  2. If he needs the JAX-WS module running (which is only on a
jdk
> 1.5
> > >>> environment)
> > >>>
> > >>>> jaxen-1.1.1.jar                       XPath engine - where is
> this
> > >>>> used?
> > >>>
> > >>> AXIOM has a Jaxen based Xpath implementation and this jar has
the
> core
> > >>> Jaxen classes for it
> > >>>
> > >>>> jettison-1.0-RC1.jar                  JSON StAX parser
> > >>>
> > >>>> jibx-bind-1.1.5.jar                   Related to JAXB?
> > >>>> jibx-run-1.1.5.jar                    Related to JAXB?
> > >>>
> > >>> Nope. Jibx is an alternate databinding. My guess is one would
need
> > >>> these only to use Jibx generated code (databinding - either on
> server
> > >>> side or client side)
> > >>>
> > >>>> juli-6.0.10.jar                       ?
> > >>>
> > >>> Juli is an alternate implementation to Java.util logging from
> tomcat.
> > >>> Here is what the tomcat site says
> > >>>  "A limitation of JDK Logging appears to be the inability to
have
> > >>> per-web application logging, as the configuration is per-VM. As
a
> > >>> result, Tomcat will, in the default configuration, replace the
> default
> > >>> LogManager implementation with a container friendly
implementation
> > >>> called JULI, which addresses these shortcomings."
> > >>>
> > >>> It seems that this one is needed only when the webapp comes to
> play
> > >>>
> > >>>> log4j-1.2.14.jar                      Logging - Is this
optional?
> I
> > >>>> don't
> > >>>>                                       always want to use Log4J
-
> for
> > >>>>                                       example, when working
with
> > >>>> Eclipse.
> > >>>
> > >>> I suppose the default logging configuration with common-logging
is
> > >>> log4j. I assume we can turn it to java.util logging but most
folks
> are
> > >>> not in favor of it (it will reduce this jar though)
> > >>>
> > >>>> mail-1.4.jar                          MIME support?
> > >>>
> > >>> Yes
> > >>>
> > >>>> mex-impl-1.3.jar                      ?
> > >>>
> > >>> Metadata exchange implementation (WS-Mex).
> > >>>
> > >>>> neethi-2.0.2.jar                      WS Policy - Is this
> optional?
> > >>>
> > >>> I don't think so. This would be required both at runtime and
> codegen
> > >>> time to process policies
> > >>>
> > >>>> soapmonitor-1.3.jar                   Is this part of Axis2 or
> another
> > >>>>                                       project? Is this just
used
> by the
> > >>>>                                       Axis2 runtime or is it
just
> the
> > >>>>                                       standalone SOAP monitor
> tool?
> > >>>
> > >>> soapmonitor has two parts - the applet and this server side
> component.
> > >>> We may be able to make it optional (i.e. pack it with the war
> only)
> > >>>
> > >>>> stax-api-1.0.1.jar                    XML pull parsing - I
think
> this
> > >>>>                                       should be replaced in the
> next
> > >>>>                                       version with Geronimo's
> > >>>>                                       API as Axiom has made the
> change
> > >>>
> > >>> I'm not sure whether the API has changed. But this jar is only
the
> API.
> > >>>
> > >>>> tribes-6.0.10.jar                     ?
> > >>>
> > >>> Clustering implementation
> > >>>
> > >>>> woden-1.0-incubating-M7b.jar          WSDL 2.0 support
> > >>>> wsdl4j-1.6.2.jar                      WSDL 1.1 support
> > >>>> wstx-asl-3.2.1.jar                    XML pull parsing
> > >>>
> > >>>> xbean-2.2.0.jar                       Looks like a competitor
to
> OSGi -
> > >>>>                                       where is this used?
> > >>>
> > >>> Don't let the name fool you :) This is actually the XMLBeans
core
> > >>> classes. There is a sepearate project called XBeans that has no
> > >>> relation to this. This one is only needed if one uses XMLBeans
> > >>> classes.
> > >>>
> > >>>> xalan-2.7.0.jar                       XSLT - Where is this
used?
> > >>>> xercesImpl-2.8.1.jar                  DOM parser - Does Axis2
> actually
> > >>>>                                       need a DOM parser? I
> thought
> > >>>>                                       everything was done with
> > >>>>                                       pull parsing.
> > >>>> xml-apis-1.3.03.jar                   DOM parser
> > >>>
> > >>> Axis2 has some DOM based code in the code generator but the
> standard
> > >>> VM DOM impl is sufficient for that. The above jars are used
> primarily
> > >>> by the SAAJ impl which has a DOM level 3 dependency. JDK  1.4
> included
> > >>> parser (Crimson) is  DOM level 2 I believe.
> > >>>
> > >>>> XmlSchema-1.3.2.jar                   XML schema support
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Lawrence
> > >>>>
> > >>> To me it seems that we can ship certain jars only for the
webapp.
> Also
> > >>> we have been discussing three types of distros,  minimal,
standard
> and
> > >>> full which will include jars in various degrees but it seemed a
> bit
> > >>> confusing at that time for the users (this was actually done in
> 1.0
> > >>> release). May be it is time to restart these discussions
> > >>>
> > >>
> > >
> > >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFHFr40jON2uBzUhh8RAknxAJ9B7dxo/NWv24j6d2tw5ZN1zmRGSQCgi3+j
> > RG8ypZ6vFeGxcT7kkSKMIDo=
> > =ggkC
> > -----END PGP SIGNATURE-----
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> Ajith Ranabahu
>
> Reading, after a certain age, diverts the mind too much from its
> creative pursuits. Any man who reads too much and uses his own brain
> too little falls into lazy habits of thinking - Albert Einstein
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message