-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok I can see at least some one is really using commons-logging. I understand and withdraw my proposal to remove the commons-logging. And Oleg, well it might be the case that other jars also might have dependencies on commons-logging, so we will have to live with it.
Thanks, Chinthaka robert lazarski wrote: > 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 <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> 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:[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: >>>> 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: [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] >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> 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] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHJJpSjON2uBzUhh8RAmyxAKCOidCQhOKVvmOHFsf3Po58dmnqwQCeK7ZQ I3bk1wnUzquG7uW8XWCKwXs= =GZ4p -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
