On Apr 21, 2009, at 3:03 PM, John Bollinger wrote:
I confess that I don't understand the portal environment very well,
but if I'm following this correctly then PLUTO-553 is a symptom of a
more fundamental issue: objects in a Pluto portlet cannot rely on
the context classloader to be the correct one from which to obtain
resources. This arises because -- as I understand it -- Pluto
provides portlet isolation analogous to the isolation of distinct
webapps in a servlet container, but unlike a servlet container, it
allows one portlet to invoke methods on the live objects of another,
not changing the context classloader when such cross-context method
invocations occur.
If I have analyzed that correctly then I would account it a Pluto
bug, not a JCL bug.
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.
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.
What your answer basically says is, commons logging only supports the
servlet spec, not the portlet spec. I guess this falls in line with https://issues.apache.org/jira/browse/LOGGING-124?
Out of curiosity, if commons-logging doesn't work in an OSGi
container then how can any commons components do logging there?
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
