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?
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
