commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Bollinger <>
Subject Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Date Tue, 21 Apr 2009 22:03:17 GMT
I confess that I don't understand the portal environment very well, but if I'm following this
correctly then PLUTO-553 is a symptom of a more fundamental issue: objects in a Pluto portlet
cannot rely on the context classloader to be the correct one from which to obtain resources.
 This arises because -- as I understand it -- Pluto provides portlet isolation analogous to
the isolation of distinct
webapps in a servlet container, but unlike a servlet container, it
allows one portlet to invoke methods on the live objects of another, not changing the context
classloader when such cross-context method invocations occur.

If I have analyzed that correctly then I would account it a Pluto bug, not a JCL bug.


From: Ralph Goers <>
To: Commons Developers List <>
Sent: Tuesday, April 21, 2009 3:25:32 PM
Subject: Re: commons-logging unsuited for cross-context webapplication invocation usage -
migrating to slf4j?

On Apr 21, 2009, at 11:59 AM, Dennis Lundberg wrote:

> I'm not that experienced in writing portlets or how the portlet
> container works. Can you please try to explain in more detail what the
> problem is.
> Commons Logging works great in a servlet container like Tomcat. Every
> webapp can have their own version of commons-logging and their own
> configuration. How does the portlet container use case differ from this?
> Do you configure Commons Logging explicitly, by using a
> file or are you relying on auto discovery? In
> my experience you you should *always* configure the logging
> implementation explicitly if you want deterministic results.

As I said in an earlier post, I follow the various portlet mailing lists but really have very
little to do with the issue they are experiencing. It is documented at

In a nutshell though, the Portal is a War. Individual portlets are packaged as separate war
files and are run under the direction of the main portal war. They seem to want all the portlets
to use the logging configuration of the portal. Personally, I'm not sure what they are saying
they want makes sense, but I guess the point is that even if it doesn't they should still
be able to do it.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message