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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
