commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Date Fri, 24 Apr 2009 08:53:34 GMT
Mark Thomas wrote:
> Ate Douma wrote:
>> When Pluto needs to "aggregate" the content of this TestPortlet, it
>> invokes it render(PortletRequest, PortletResponse) method using a
>> "cross-context" call from the Pluto web application to the "test" web
>> application.
>> The TestPortlet.render method receives the PortletRequest object (as
>> loaded from the Pluto WEB-INF/lib) and invokes its
>> PortletRequest.getPortletPreferences() method. If the PortletPreferences
>> class hasn't been accessed yet before, this will cause the ClassLoader
>> of PortletRequest, being the Pluto webapp ClassLoader, to now load the
>> PortletPreferences class.
>> But, because the current ContextClassLoader is the "test" webapp
>> ClassLoader, LogFactory will lookup the logger implementation from the
>> "test" webapp...
>> With as result that logging output for the PortletPreferences class will
>> end up in the target as specified by the "test" webapp, not in the one
>> (as expected) as configured for the Pluto webapp.
> I have seen similar issues in Tomcat's internal logging with
> java.util.logging, log4j and commons-logging. Why will this be any
> different with slf4j?
Because sfl4j does not use the ContextClassLoader to determine the logger instance but compile-time
Exactly the reason why CL doesn't work and slf4j does.
I think using slf4j for Tomcat internal logging would solve this too.

>> The only possible workaround I could come up with was extending
>> LogFactory itself and temporarily switching/enforcing the current
>> ContextClassLoader to that of the class itself, but obviously we didn't
>> even consider that as a real option.
> In Tomcat, the issue was (mainly) log objects for internal components
> being created and loaded by a web application class loader. This was a
> particular issue for Jasper, the JSP engine, as it interacts quite
> closely with web apps. We solved this by ensuring that the logs were
> created during Tomcat start.
Sure, that will work *if* you manage to prime/pre-load all loggers upfront.
For a webserver that might be doable (for its internal libraries), but for an embeddable component
like a portletcontainer and definitely 
for a highly configurable and extendable portal like Jetspeed that would put too much runtime
overhead and an indeterminable configuration 
nightmare for the end users/integrators.
> Would a similar solution not work for Pluto? Use a
> ServletContextListener to create your log instances when the portlet
> container web appilcation starts?
And start scanning and preloading all classes from WEB-INF/classes and WEB-INF/lib?
Replacing CL with slf4j is by far a more transparent and easier solution than that.


> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message