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:19:05 GMT

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

> Ralph Goers wrote:
>> I saw your update on PLUTO-553. I suggest you read the JSR 286  
>> Portlet spec. Portlets can access resources using the  
>> PortletContext's getResource method. This corresponds to the  
>> portlet War's servlet context. In addition, portlets also have  
>> access to the PortalContext.
> Right, but I don't see how that's relevant.  Surely  
> PortletContext.getResource() should be and is using the portlet  
> app's context classloader, but PortalContext does not provide an  
> analogous getResource() method or similar that could reasonably be  
> interpreted to require a classloader resource lookup.
>> It is important to remember that when a portlet war is "deployed"  
>> by a portal a new servlet gets added by the portal container. This  
>> servlet "bridges" between the portal and the portlet.
> I'm fairly confident that JSR-286 specifies none of those details,  
> so from a standard-compliance perspective that bit is irrelevant.  I  
> also acknowledge, however, that that may not be a useful perspective  
> to take if Pluto is already committed to the architecture you  
> describe, and furthermore that it sounds like a reasonable  
> architecture.

In order to implement the spec EVERY portal must implement something  
similar. It is simply not possible to have a "generic" portlet  
communicate with it's portal container unless a portion of the  
container is "injected" into the porlet webapp somehow. No, you won't  
see that called out in the spec. They leave that part up to the  
container to do whatever they need to do to make it work.

>> Most likely this is where Pluto wants the logging framework to use  
>> the Portal's class loader.
> I don't think so.  The issue description says it's about  
> "determining the LogFactory for a portal/portletcontainer class  
> while being cross-context *invoked from a portlet  
> application*" (emphasis added).  I'm having trouble figuring out the  
> failure scenario too, and I'm not sure that when I understand it I  
> will agree that Pluto was doing the wrong thing.

Does it really matter that you understand what they are trying to do?   
What should matter is what they are trying to do doesn't work properly  
and they couldn't find a work around.

I'm still at a loss as to how this conversation has devolved to this.  
This post was meant as an example as to why yet another project is  
switching away from Commons Logging.

I'll ask again. What is next for Commons Logging? Is there any point  
in enhancing it to emulate SLF4J? Should it just stay more or less as  
it is while it slowly loses its customer base?


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

View raw message