Hi Ajith, Without arguing for or against this change I'm wondering why you think it will "be a long hard effort" to make this change. With tools support from the likes of Eclipse it seems like it would be rather trivial to change from one logging call to another. What am I missing?
Thanks, Lawrence "Ajith Ranabahu" <[EMAIL PROTECTED]> 10/22/2007 06:39 PM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject Re: [Axis2] Understanding Axis2 dependencies Hi Tom, 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. > Agreed :) But if we are to change all the commons logging references it will be a long hard effort (just speculation though). If my understanding is right, we can set the configuration to use the java.util logging quite easily and not ship the log4j.jar. > -- > 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] > > -- 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]
