RE: Commons Logging

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: Commons Logging

Bordet, Simone
Greg,

> The main problem with commons logging is the discovery mechanism.
> While Jetty has a very flexible classloader, it still fails with
> commons logging discovery when a webapp calls back to API in
> Jetty for the first time and new classes are loaded.
>
> So the solution I have come to is to either totally avoid
> commons discovery and directly call the Jetty logging factory,
> or to do the factory discovery once and only once and them use
> that discovered factory for all of Jetty.
>
> Do do this, Jetty now calls it's own LogFactory facade.
> If the system property org.mortbay.log.LogFactory.noDiscovery
> is true, then a static instance of the Jetty Log factory is used.
> if it is false (or not set), then normal commons discovery is
> performed
> once, and the resulting factory used for all of Jetty.
>
> With this change, I have been able to configure Jetty to use its
> own commons logging implementation and for a webapp to use a different
> instance of commons logging which uses log4j.
>
> This is checked into CVS now.  Your milage may vary, so I'd
> really appreciate
> if people could test CVS head before I do a RC release this weekend.

Jetty 5.1.5rc0 ships an old version of common-logging, 1.0.3.
My web app is under webapps/logging/:

index.jsp
WEB-INF/
WEB-INF/web.xml
WEB-INF/classes/log4j.properties
WEB-INF/lib/commons-logging-1.0.4.jar
WEB-INF/lib/log4j-1.2.9.jar

web.xml is 2.4, and it's completely empty.
I did not modify start.config, and when I run jetty:

java -jar start.jar

I get:
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger

Using -Dorg.mortbay.log.LogFactory.noDiscovery=true gives the same
result.

Adding a jetty-web.xml with:

<Set name="classLoaderJava2Compliant">false</Set>

changes the exception to:

Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.Log4JLogger does not implement Log

Using -Dorg.mortbay.log.LogFactory.noDiscovery=true gives the same
result.

Adding org.apache.commons.logging. to serverClasses in jetty-web.xml
does not change the result.

Updating commons-logging to 1.0.4 under $jetty.home/ext does not seem to
help.

Adding log4j to $jetty.home/ext does indeed allow the web app to start,
but the JSP is:

<%@ page import="org.apache.commons.logging.Log"%>
<%@ page import="org.apache.commons.logging.LogFactory"%>
<%!
   private Log logger = LogFactory.getLog(getClass().getName());
%>
<%
   logger.info("logger: " + logger.getClass().getClassLoader());
   logger.info("context: " +
Thread.currentThread().getContextClassLoader());
%>

This prints:

logger: StartLoader[...]
context: ContextLoader@25197736

And I get jetty logging with the format of the log4j.properties under
WEB-INF/classes, which I suspect will mess up when having multiple web
apps.

Thanks,

Simon


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Commons Logging

Greg Wilkins-5

Bugger!!!!!

It looks like 1.0.4 is being smarter and somehow detecting the other
version of commons logging and doing a dummy spit!!!!

I will have to investigate more.... but it is pretty obvious that
the developers of commons logging really only want a single logger
hierarchy in the JVM....

I think I will do a Jetty 5.2 shortly without commons logging...

cheers




Bordet, Simone wrote:

> Greg,
>
>
>>The main problem with commons logging is the discovery mechanism.
>>While Jetty has a very flexible classloader, it still fails with
>>commons logging discovery when a webapp calls back to API in
>>Jetty for the first time and new classes are loaded.
>>
>>So the solution I have come to is to either totally avoid
>>commons discovery and directly call the Jetty logging factory,
>>or to do the factory discovery once and only once and them use
>>that discovered factory for all of Jetty.
>>
>>Do do this, Jetty now calls it's own LogFactory facade.
>>If the system property org.mortbay.log.LogFactory.noDiscovery
>>is true, then a static instance of the Jetty Log factory is used.
>>if it is false (or not set), then normal commons discovery is
>>performed
>>once, and the resulting factory used for all of Jetty.
>>
>>With this change, I have been able to configure Jetty to use its
>>own commons logging implementation and for a webapp to use a different
>>instance of commons logging which uses log4j.
>>
>>This is checked into CVS now.  Your milage may vary, so I'd
>>really appreciate
>>if people could test CVS head before I do a RC release this weekend.
>
>
> Jetty 5.1.5rc0 ships an old version of common-logging, 1.0.3.
> My web app is under webapps/logging/:
>
> index.jsp
> WEB-INF/
> WEB-INF/web.xml
> WEB-INF/classes/log4j.properties
> WEB-INF/lib/commons-logging-1.0.4.jar
> WEB-INF/lib/log4j-1.2.9.jar
>
> web.xml is 2.4, and it's completely empty.
> I did not modify start.config, and when I run jetty:
>
> java -jar start.jar
>
> I get:
> Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
>
> Using -Dorg.mortbay.log.LogFactory.noDiscovery=true gives the same
> result.
>
> Adding a jetty-web.xml with:
>
> <Set name="classLoaderJava2Compliant">false</Set>
>
> changes the exception to:
>
> Caused by: org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Class
> org.apache.commons.logging.impl.Log4JLogger does not implement Log
>
> Using -Dorg.mortbay.log.LogFactory.noDiscovery=true gives the same
> result.
>
> Adding org.apache.commons.logging. to serverClasses in jetty-web.xml
> does not change the result.
>
> Updating commons-logging to 1.0.4 under $jetty.home/ext does not seem to
> help.
>
> Adding log4j to $jetty.home/ext does indeed allow the web app to start,
> but the JSP is:
>
> <%@ page import="org.apache.commons.logging.Log"%>
> <%@ page import="org.apache.commons.logging.LogFactory"%>
> <%!
>    private Log logger = LogFactory.getLog(getClass().getName());
> %>
> <%
>    logger.info("logger: " + logger.getClass().getClassLoader());
>    logger.info("context: " +
> Thread.currentThread().getContextClassLoader());
> %>
>
> This prints:
>
> logger: StartLoader[...]
> context: ContextLoader@25197736
>
> And I get jetty logging with the format of the log4j.properties under
> WEB-INF/classes, which I suspect will mess up when having multiple web
> apps.
>
> Thanks,
>
> Simon
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Commons Logging

Greg Wilkins-5


DOH!

The problem is that Jetty still uses Jasper and Jasper uses
commons-logging, but it does not use the discovery avoidance
"trick" that the rest of Jetty uses.

I was able to get axis to work with it's own commons logging instance
by moving the jasper jars into WEB-INF lib - but that is bollocks.

There is obviously something I'm missing with this.....

It is also a bitch that jasper uses commons logging, as it makes
it very difficult to jump commons logging.




Greg Wilkins wrote:

> Bugger!!!!!
>
> It looks like 1.0.4 is being smarter and somehow detecting the other
> version of commons logging and doing a dummy spit!!!!
>
> I will have to investigate more.... but it is pretty obvious that
> the developers of commons logging really only want a single logger
> hierarchy in the JVM....
>
> I think I will do a Jetty 5.2 shortly without commons logging...
>
> cheers
>
>
>
>
> Bordet, Simone wrote:
>
>>Greg,
>>
>>
>>
>>>The main problem with commons logging is the discovery mechanism.
>>>While Jetty has a very flexible classloader, it still fails with
>>>commons logging discovery when a webapp calls back to API in
>>>Jetty for the first time and new classes are loaded.
>>>
>>>So the solution I have come to is to either totally avoid
>>>commons discovery and directly call the Jetty logging factory,
>>>or to do the factory discovery once and only once and them use
>>>that discovered factory for all of Jetty.
>>>
>>>Do do this, Jetty now calls it's own LogFactory facade.
>>>If the system property org.mortbay.log.LogFactory.noDiscovery
>>>is true, then a static instance of the Jetty Log factory is used.
>>>if it is false (or not set), then normal commons discovery is
>>>performed
>>>once, and the resulting factory used for all of Jetty.
>>>
>>>With this change, I have been able to configure Jetty to use its
>>>own commons logging implementation and for a webapp to use a different
>>>instance of commons logging which uses log4j.
>>>
>>>This is checked into CVS now.  Your milage may vary, so I'd
>>>really appreciate
>>>if people could test CVS head before I do a RC release this weekend.
>>
>>
>>Jetty 5.1.5rc0 ships an old version of common-logging, 1.0.3.
>>My web app is under webapps/logging/:
>>
>>index.jsp
>>WEB-INF/
>>WEB-INF/web.xml
>>WEB-INF/classes/log4j.properties
>>WEB-INF/lib/commons-logging-1.0.4.jar
>>WEB-INF/lib/log4j-1.2.9.jar
>>
>>web.xml is 2.4, and it's completely empty.
>>I did not modify start.config, and when I run jetty:
>>
>>java -jar start.jar
>>
>>I get:
>>Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
>>
>>Using -Dorg.mortbay.log.LogFactory.noDiscovery=true gives the same
>>result.
>>
>>Adding a jetty-web.xml with:
>>
>><Set name="classLoaderJava2Compliant">false</Set>
>>
>>changes the exception to:
>>
>>Caused by: org.apache.commons.logging.LogConfigurationException:
>>org.apache.commons.logging.LogConfigurationException: Class
>>org.apache.commons.logging.impl.Log4JLogger does not implement Log
>>
>>Using -Dorg.mortbay.log.LogFactory.noDiscovery=true gives the same
>>result.
>>
>>Adding org.apache.commons.logging. to serverClasses in jetty-web.xml
>>does not change the result.
>>
>>Updating commons-logging to 1.0.4 under $jetty.home/ext does not seem to
>>help.
>>
>>Adding log4j to $jetty.home/ext does indeed allow the web app to start,
>>but the JSP is:
>>
>><%@ page import="org.apache.commons.logging.Log"%>
>><%@ page import="org.apache.commons.logging.LogFactory"%>
>><%!
>>   private Log logger = LogFactory.getLog(getClass().getName());
>>%>
>><%
>>   logger.info("logger: " + logger.getClass().getClassLoader());
>>   logger.info("context: " +
>>Thread.currentThread().getContextClassLoader());
>>%>
>>
>>This prints:
>>
>>logger: StartLoader[...]
>>context: ContextLoader@25197736
>>
>>And I get jetty logging with the format of the log4j.properties under
>>WEB-INF/classes, which I suspect will mess up when having multiple web
>>apps.
>>
>>Thanks,
>>
>>Simon
>>
>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Commons Logging

Ceki Gulcu-2
In reply to this post by Greg Wilkins-5


If my memory serves me right, despite what the version numbers
suggest, JCL 1.0.3 is not so insignificantly different than version
1.0.4. For those interested, I've written document describing some of
the problems encountered when using JCL 1.0.4.  It can be found at

   http://www.qos.ch/logging/classloader.jsp

You may (or may not) find it useful.

At 10:28 PM 8/23/2005, you wrote:

>Bugger!!!!!
>
>It looks like 1.0.4 is being smarter and somehow detecting the other
>version of commons logging and doing a dummy spit!!!!
>
>I will have to investigate more.... but it is pretty obvious that
>the developers of commons logging really only want a single logger
>hierarchy in the JVM....
>
>I think I will do a Jetty 5.2 shortly without commons logging...
>
>cheers
>

--
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Commons Logging

Attila Szegedi-4
Frankly, I loathe JCL, and am probably not alone with it. One Apache  
officer even admitted to me in person that he avoids using JCL in his  
projects. Consider this: I had to add JCL into my project as a 3rd party  
lib (Spring) uses it. Then I started having memory leaks. My system  
implements hot code reloading, and it turned out the memory leak is  
because JCL internally keeps a strong reference to the class loader and  
I'm expected to explicitly invoke

LogFactory.release(classLoader);

in my code when discarding a class loader to make JCL let go of it. Now,  
my code -- that otherwise doesn't use JCL at all -- suddenly needs to have  
JCL as its compile dependency in order to invoke  
LogFactory.release(classLoader)! Hideous! Brings back the memory of days  
when I coded in C and had to manually cope with memory  
allocators/deallocators of 3rd party libraries my code relied upon. I  
wrote in detail about this JCL issue and several other similar phenomenons  
in <http://www.szegedi.org/articles/memleak.html>.

Attila.

--
home: http://www.szegedi.org
weblog: http://www.jroller.com/page/aszegedi

On Tue, 23 Aug 2005 23:23:34 +0200, Ceki Gülcü <[hidden email]> wrote:

>
>
> If my memory serves me right, despite what the version numbers
> suggest, JCL 1.0.3 is not so insignificantly different than version
> 1.0.4. For those interested, I've written document describing some of
> the problems encountered when using JCL 1.0.4.  It can be found at
>
>    http://www.qos.ch/logging/classloader.jsp
>
> You may (or may not) find it useful.
>
> At 10:28 PM 8/23/2005, you wrote:
>
>> Bugger!!!!!
>>
>> It looks like 1.0.4 is being smarter and somehow detecting the other
>> version of commons logging and doing a dummy spit!!!!
>>
>> I will have to investigate more.... but it is pretty obvious that
>> the developers of commons logging really only want a single logger
>> hierarchy in the JVM....
>>
>> I think I will do a Jetty 5.2 shortly without commons logging...
>>
>> cheers
>>
>


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Commons Logging

Ceki Gulcu-2
In reply to this post by Greg Wilkins-5

Greg,

How about if SLF4J implementations also carried a copy of commons logging
classes implemented over the SLF4J API? You could then replace
commons-logging.jar with slf4j-SOMEBINDING.jar. Components requiring
commons-logging would continue to function as before (but without the
headaches).

Would that be something you'd be interested in?

At 10:47 PM 8/23/2005, you wrote:


>DOH!
>
>The problem is that Jetty still uses Jasper and Jasper uses
>commons-logging, but it does not use the discovery avoidance
>"trick" that the rest of Jetty uses.
>
>I was able to get axis to work with it's own commons logging instance
>by moving the jasper jars into WEB-INF lib - but that is bollocks.
>
>There is obviously something I'm missing with this.....
>
>It is also a bitch that jasper uses commons logging, as it makes
>it very difficult to jump commons logging.
>
>
>
>
>Greg Wilkins wrote:
> > Bugger!!!!!
> >
> > It looks like 1.0.4 is being smarter and somehow detecting the other
> > version of commons logging and doing a dummy spit!!!!
> >
> > I will have to investigate more.... but it is pretty obvious that
> > the developers of commons logging really only want a single logger
> > hierarchy in the JVM....
> >
> > I think I will do a Jetty 5.2 shortly without commons logging...
> >
> > cheers
> >
> >
> >
> >
> > Bordet, Simone wrote:
> >
> >>Greg,
> >>
> >>
> >>
> >>>The main problem with commons logging is the discovery mechanism.
> >>>While Jetty has a very flexible classloader, it still fails with
> >>>commons logging discovery when a webapp calls back to API in
> >>>Jetty for the first time and new classes are loaded.
> >>>
> >>>So the solution I have come to is to either totally avoid
> >>>commons discovery and directly call the Jetty logging factory,
> >>>or to do the factory discovery once and only once and them use
> >>>that discovered factory for all of Jetty.
> >>>
> >>>Do do this, Jetty now calls it's own LogFactory facade.
> >>>If the system property org.mortbay.log.LogFactory.noDiscovery
> >>>is true, then a static instance of the Jetty Log factory is used.
> >>>if it is false (or not set), then normal commons discovery is
> >>>performed
> >>>once, and the resulting factory used for all of Jetty.
> >>>
> >>>With this change, I have been able to configure Jetty to use its
> >>>own commons logging implementation and for a webapp to use a different
> >>>instance of commons logging which uses log4j.
> >>>
> >>>This is checked into CVS now.  Your milage may vary, so I'd
> >>>really appreciate
> >>>if people could test CVS head before I do a RC release this weekend.
> >>
> >>
> >>Jetty 5.1.5rc0 ships an old version of common-logging, 1.0.3.
> >>My web app is under webapps/logging/:
> >>
> >>index.jsp
> >>WEB-INF/
> >>WEB-INF/web.xml
> >>WEB-INF/classes/log4j.properties
> >>WEB-INF/lib/commons-logging-1.0.4.jar
> >>WEB-INF/lib/log4j-1.2.9.jar
> >>
> >>web.xml is 2.4, and it's completely empty.
> >>I did not modify start.config, and when I run jetty:
> >>
> >>java -jar start.jar
> >>
> >>I get:
> >>Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
> >>
> >>Using -Dorg.mortbay.log.LogFactory.noDiscovery=true gives the same
> >>result.
> >>
> >>Adding a jetty-web.xml with:
> >>
> >><Set name="classLoaderJava2Compliant">false</Set>
> >>
> >>changes the exception to:
> >>
> >>Caused by: org.apache.commons.logging.LogConfigurationException:
> >>org.apache.commons.logging.LogConfigurationException: Class
> >>org.apache.commons.logging.impl.Log4JLogger does not implement Log
> >>
> >>Using -Dorg.mortbay.log.LogFactory.noDiscovery=true gives the same
> >>result.
> >>
> >>Adding org.apache.commons.logging. to serverClasses in jetty-web.xml
> >>does not change the result.
> >>
> >>Updating commons-logging to 1.0.4 under $jetty.home/ext does not seem to
> >>help.
> >>
> >>Adding log4j to $jetty.home/ext does indeed allow the web app to start,
> >>but the JSP is:
> >>
> >><%@ page import="org.apache.commons.logging.Log"%>
> >><%@ page import="org.apache.commons.logging.LogFactory"%>
> >><%!
> >>   private Log logger = LogFactory.getLog(getClass().getName());
> >>%>
> >><%
> >>   logger.info("logger: " + logger.getClass().getClassLoader());
> >>   logger.info("context: " +
> >>Thread.currentThread().getContextClassLoader());
> >>%>
> >>
> >>This prints:
> >>
> >>logger: StartLoader[...]
> >>context: ContextLoader@25197736
> >>
> >>And I get jetty logging with the format of the log4j.properties under
> >>WEB-INF/classes, which I suspect will mess up when having multiple web
> >>apps.
> >>
> >>Thanks,
> >>
> >>Simon
> >>
> >>
> >>-------------------------------------------------------
> >>SF.Net email is Sponsored by the Better Software Conference & EXPO
> >>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> >>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> >>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>jetty-discuss mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/jetty-discuss

--
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Commons Logging

Greg Wilkins-5

Ceki,

Thanks for the offer, but it is not really an API issue.  It is pretty
trivial for me to change all the logging in the Jetty source code.

It is more of a deployment issue, that while jetty is in the 5 point 1 point something
series it is not really a suitable time to change the logging infrastructure.

I have also noticed that tomcat does not support multiple versions of JCL
and so that even if your webapp has a version of JCL in WEB-INF/lib, you get
the tomcat copy of the classes.   Jetty now mimics this behaviour by default (was
a possibility before but was switched off).    This improves the out-of-the-box
behaviour, but does not really solve all the life cycle and discovery issues.

So I'm a little more content with leaving Jetty 5 on JCL for now.

However, having a jcl-slf4j-SOMEBINDING.jar is a very good idea for
help adoption of slf4j.   Of course you'd have to deal with the "I want trace"
issue :-)

cheers



Ceki Gülcü wrote:

>
> Greg,
>
> How about if SLF4J implementations also carried a copy of commons
> logging classes implemented over the SLF4J API? You could then replace
> commons-logging.jar with slf4j-SOMEBINDING.jar. Components requiring
> commons-logging would continue to function as before (but without the
> headaches).
>
> Would that be something you'd be interested in?
>
> At 10:47 PM 8/23/2005, you wrote:
>
>
>> DOH!
>>
>> The problem is that Jetty still uses Jasper and Jasper uses
>> commons-logging, but it does not use the discovery avoidance
>> "trick" that the rest of Jetty uses.
>>
>> I was able to get axis to work with it's own commons logging instance
>> by moving the jasper jars into WEB-INF lib - but that is bollocks.
>>
>> There is obviously something I'm missing with this.....
>>
>> It is also a bitch that jasper uses commons logging, as it makes
>> it very difficult to jump commons logging.
>>
>>
>>
>>
>> Greg Wilkins wrote:
>> > Bugger!!!!!
>> >
>> > It looks like 1.0.4 is being smarter and somehow detecting the other
>> > version of commons logging and doing a dummy spit!!!!
>> >
>> > I will have to investigate more.... but it is pretty obvious that
>> > the developers of commons logging really only want a single logger
>> > hierarchy in the JVM....
>> >
>> > I think I will do a Jetty 5.2 shortly without commons logging...
>> >
>> > cheers
>> >
>> >
>> >
>> >
>> > Bordet, Simone wrote:
>> >
>> >>Greg,
>> >>
>> >>
>> >>
>> >>>The main problem with commons logging is the discovery mechanism.
>> >>>While Jetty has a very flexible classloader, it still fails with
>> >>>commons logging discovery when a webapp calls back to API in
>> >>>Jetty for the first time and new classes are loaded.
>> >>>
>> >>>So the solution I have come to is to either totally avoid
>> >>>commons discovery and directly call the Jetty logging factory,
>> >>>or to do the factory discovery once and only once and them use
>> >>>that discovered factory for all of Jetty.
>> >>>
>> >>>Do do this, Jetty now calls it's own LogFactory facade.
>> >>>If the system property org.mortbay.log.LogFactory.noDiscovery
>> >>>is true, then a static instance of the Jetty Log factory is used.
>> >>>if it is false (or not set), then normal commons discovery is
>> >>>performed
>> >>>once, and the resulting factory used for all of Jetty.
>> >>>
>> >>>With this change, I have been able to configure Jetty to use its
>> >>>own commons logging implementation and for a webapp to use a different
>> >>>instance of commons logging which uses log4j.
>> >>>
>> >>>This is checked into CVS now.  Your milage may vary, so I'd
>> >>>really appreciate
>> >>>if people could test CVS head before I do a RC release this weekend.
>> >>
>> >>
>> >>Jetty 5.1.5rc0 ships an old version of common-logging, 1.0.3.
>> >>My web app is under webapps/logging/:
>> >>
>> >>index.jsp
>> >>WEB-INF/
>> >>WEB-INF/web.xml
>> >>WEB-INF/classes/log4j.properties
>> >>WEB-INF/lib/commons-logging-1.0.4.jar
>> >>WEB-INF/lib/log4j-1.2.9.jar
>> >>
>> >>web.xml is 2.4, and it's completely empty.
>> >>I did not modify start.config, and when I run jetty:
>> >>
>> >>java -jar start.jar
>> >>
>> >>I get:
>> >>Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
>> >>
>> >>Using -Dorg.mortbay.log.LogFactory.noDiscovery=true gives the same
>> >>result.
>> >>
>> >>Adding a jetty-web.xml with:
>> >>
>> >><Set name="classLoaderJava2Compliant">false</Set>
>> >>
>> >>changes the exception to:
>> >>
>> >>Caused by: org.apache.commons.logging.LogConfigurationException:
>> >>org.apache.commons.logging.LogConfigurationException: Class
>> >>org.apache.commons.logging.impl.Log4JLogger does not implement Log
>> >>
>> >>Using -Dorg.mortbay.log.LogFactory.noDiscovery=true gives the same
>> >>result.
>> >>
>> >>Adding org.apache.commons.logging. to serverClasses in jetty-web.xml
>> >>does not change the result.
>> >>
>> >>Updating commons-logging to 1.0.4 under $jetty.home/ext does not
>> seem to
>> >>help.
>> >>
>> >>Adding log4j to $jetty.home/ext does indeed allow the web app to start,
>> >>but the JSP is:
>> >>
>> >><%@ page import="org.apache.commons.logging.Log"%>
>> >><%@ page import="org.apache.commons.logging.LogFactory"%>
>> >><%!
>> >>   private Log logger = LogFactory.getLog(getClass().getName());
>> >>%>
>> >><%
>> >>   logger.info("logger: " + logger.getClass().getClassLoader());
>> >>   logger.info("context: " +
>> >>Thread.currentThread().getContextClassLoader());
>> >>%>
>> >>
>> >>This prints:
>> >>
>> >>logger: StartLoader[...]
>> >>context: ContextLoader@25197736
>> >>
>> >>And I get jetty logging with the format of the log4j.properties under
>> >>WEB-INF/classes, which I suspect will mess up when having multiple web
>> >>apps.
>> >>
>> >>Thanks,
>> >>
>> >>Simon
>> >>
>> >>
>> >>-------------------------------------------------------
>> >>SF.Net email is Sponsored by the Better Software Conference & EXPO
>> >>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>> Practices
>> >>Agile & Plan-Driven Development * Managing Projects & Teams *
>> Testing & QA
>> >>Security * Process Improvement & Measurement *
>> http://www.sqe.com/bsce5sf
>> >
>> >
>> >
>> >
>> > -------------------------------------------------------
>> > SF.Net email is Sponsored by the Better Software Conference & EXPO
>> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>> Practices
>> > Agile & Plan-Driven Development * Managing Projects & Teams *
>> Testing & QA
>> > Security * Process Improvement & Measurement *
>> http://www.sqe.com/bsce5sf
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>> Practices
>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
>> & QA
>> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>> _______________________________________________
>> jetty-discuss mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>
>



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Commons Logging

Ceki Gulcu-2


At 02:35 PM 8/26/2005, you wrote:

>Ceki,
>
>Thanks for the offer, but it is not really an API issue.  It is pretty
>trivial for me to change all the logging in the Jetty source code.
 >
>It is more of a deployment issue, that while jetty is in the 5 point 1
>point something
>series it is not really a suitable time to change the logging infrastructure.

That is understandable.

>I have also noticed that tomcat does not support multiple versions of JCL
>and so that even if your webapp has a version of JCL in WEB-INF/lib, you get
>the tomcat copy of the classes.   Jetty now mimics this behaviour by
>default (was
>a possibility before but was switched off).    This improves the
>out-of-the-box
>behaviour, but does not really solve all the life cycle and discovery issues.
>
>So I'm a little more content with leaving Jetty 5 on JCL for now.

No problem. My previous message was really a reaction to your comment:

   It is also a bitch that jasper uses commons logging, as it makes
   it very difficult to jump commons logging.

>However, having a jcl-slf4j-SOMEBINDING.jar is a very good idea for
>help adoption of slf4j.   Of course you'd have to deal with the "I want trace"
>issue :-)

Trace? The term never came up before. Just kidding :-)

>cheers

--
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss