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:47:01 GMT
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.

> Most likely this is where Pluto wants the logging framework to use the Portal's class

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.


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