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