commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Date Wed, 22 Apr 2009 03:12:08 GMT

On Apr 21, 2009, at 7:08 PM, John Bollinger wrote:

> 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.

The cross-context invocation allows Pluto to "communicate" with the  
Servlet that it injected into the Portlet war. Tomcat has a setting in  
server.xml which when set allows the ServletContext.getContext()  
method to successfully return the ServletContext for other Web  
applications running in the same host. This is what Pluto is using to  
get to the portal's context. See the really nice picture at

.  Something of this nature is required since web applications  
deployed in different wars generally can't communicate effectively  
with each other. In some portals classes are added to the servlet  
container. IIRC Pluto can also work that way but takes advantage of  
this Tomcat feature to make installation of the portal simpler.

>> 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.

You misunderstand the definition of "portlet application". A portlet  
application is a war file that contains one or more portlets. Portlets  
from different war files can appear on the same page in the portal. I  
don't believe Pluto is attempting to control the logging that occurs  
within the portlet. Unless I'm mistaken, they just want the servlet -  
and any of the portal classes it uses - to use the same logging  
mechanism that the portal itself is using.
>> 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.

I can guarantee you that Pluto is not violating SRV 9.7.2. If you put  
a servlet in your portlet war calls to getResource will behave as you  
want. Portlets don't use that API. They use the Portlet API's version  
of getResource.  Pluto is the reference implementation for JSR 286 and  
was the reference implementation for JSR 168, so it isn't like they  
are creating something that the spec didn't envision. In fact, if the  
concern you mentioned earlier regarding loading resources were true  
then Pluto would be violating PLT 23.5. Presumably the TCK has  
something that checks that.

FWIW, the portlet spec is much like the servlet spec. It defines what  
must be provided to applications but doesn't actually say how the  
container itself has to work. There are some things that the container  
has to do in order to implement the spec properly, but you won't  
necessarily see that called out in the spec. This is just one such  
case of that.

The problem here, which you don't seem to recognize, is that Pluto  
needs to do something it should be allowed to do because Tomcat allows  
it. Your answer seems to be "No, you can't".


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

View raw message