axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert lazarski" <robertlazar...@gmail.com>
Subject Re: [Axis2] Understanding Axis2 dependencies
Date Sat, 27 Oct 2007 13:11:21 GMT
I agree there are too many jars - I just did a project and it was a
drag going through all those deps.

But why are we limping with commons-logging 1.1 - because its a jar
dep? IIRC correctly almost all of the apache projects use it.
commons-logging is so well, common, you'll probably need it anyways.

Debugging via logs is a very important thing and is more complicated
than it may appear. There are not only several IDE's but several JEE
servers. I actually use axis2 in alot of these JEE servers. When you
start trying to debug axis2 via eclipse live on things like JBoss and
JPDA, some loggers like commons-logging 1.0.4 will crash hard. JBoss
is a good example of a complicated and hard to override logging
scheme.

In short, you're probably going to need commons-logging anyways since
everyone uses it, and if history is any guide its going to be left up
to the users to test any other logging on everything but tomcat. Since
JDK logging is not at all common, help may be hard to come by. So I
see pain with little benefit. I'm fighting for this because its not at
all fun to waste time on logging problems, and commons-logging 1.1
simply works everywhere axis2 has run.

Robert



On 10/27/07, Eran Chinthaka <chinthaka@opensource.lk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Robert,
>
> Yes it is not broken. But why do we wanna limp with it? If we had used a
> separate, say String class without using java.lang.String, do you wanna
> keep it, if java.lang.String serves the purpose.
> Look at how pain it is to deal with numerous jars within Axis2. I'd like
> to cut down whatever possible whenever possible.
>
> Also I totally agree with Tom's comments. We can come up with usecases
> which commons-logging becomes handy. But how many users will use it or
> come across that use case vs how many users find it difficult to set up
> Axis2 to run within their box? I agree removing just two or three jars
> won't solve the problem, but at least that will be a start.
>
> Thanks,
> Chinthaka
>
> robert lazarski wrote:
> > Um, Axis2 has been on commons-logging 1.1 since right after Axis2 1.0
> > . The most common JEE server is JBoss, and Axis2 and commons-logging
> > plays nice there. IMHO, If it aint broke, don't fix it.
> >
> > Robert
> >
> > On 10/23/07, Tom Jordahl <tjordahl@adobe.com> wrote:
> >> 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:
> > 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
> >>>>>>>>
> >>>>>>
> >>>>
> >>>>
> >> ---------------------------------------------------------------------
> 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
> >>
> >>
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHItFbjON2uBzUhh8RAuU3AJ9DWW0ztOenIU0dYIhFPWHRVLlvRQCfXJD1
> r2bLs/8a0SiJKwXorWLJuN4=
> =zRMn
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> 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