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 Wed, 22 Apr 2009 02:08:47 GMT

Ralph Goers wrote:
> It is hard to classify something a "bug" when it is working "corectly".  The portlet
spec requires that a portal container be a webapp and that it be able to deploy and control
portlets in the manner in which Pluto is doing it. That could hardly be considered a bug.

Something is not working correctly, else there would be no bug report.  Having now spent some
quality time with the JSR-286
spec and re-read the PLUTO-553 description a couple more times, I
think I can speak a little more intelligently about this.  The portlet spec requires that
"portlet applications" be web applications, and that portlet containers be or extend servlet
containers.  That is not the problem.  The problem is that any object operating in a servlet
environment, including a portlet environment, should be able to assume that the current context
classloader is an appropriate one for the current operating context, yet apparently this is
not always the case in Pluto.  I assert that this presents problems for more than just JCL.

PLUTO-553 makes some hay about "cross-context" invocations, but the portlet spec doesn't speak
at all to any such activity, so I reject the premise that a portlet container must support
such a thing to be considered to work correctly.

> Think about it this way. The end user sees a page with multiple widgets on it. The end
user can interact with any of them. All pluto wants is that the logging that occurs work the
same no matter which portlet the end user interacts with. That doesn't seem too unreasonable
to me.

All portlets in the same portlet application already log the same, else it is definitely a
Pluto bug. You would have to do something very strange to make that not work.  In any case,
I don't think the issue is that all portlets should log the same.  If that were the case then
the solution would be to configure logging at the container level instead of inside each portlet
application.  That would provide the same logging for all portlet applications, even in the
face of "cross-context" invocations.

> What your answer basically says is, commons logging only supports the servlet spec, not
the portlet spec. I guess this falls in line with
Out of curiosity, if commons-logging doesn't work in an OSGi container then how can any commons
components do logging there?

I don't know about OSGi, but no, I'm not saying that commons-logging does not support the
portlet spec.  I see nothing in the portlet spec, including the few OSGi-related comments,
that makes it any less compatible with commons-logging than the servlet spec (which it extends).
 On the contrary, it sounds like Pluto is probably failing to satisfy section SRV.9.7.2 of
Servlet 2.4, concerning web application classloading, and I speculate that if it were meeting
that requirement in a reasonable way then there would be no problem with JCL.


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