On Wed, Apr 22, 2009 at 12:03 AM, John Bollinger <thinma...@yahoo.com> 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.
The thing is that there is something like a "common" ClassLoader in
Pluto (and, most possibly, in all Portlet servers).
But that is nothing special: We know that from Tomcat as well. (Of
course, the common ClassLoader isn't endorsed by the Servlet
specification, but we all know that it is a necessity.)
Now, if we start using the various class loaders, we'll have class
loading issues with JCL. (Most of them, because people don't
understand the concept.) But you can be sure (and that's where I
absolutely disagree with PLUTO-533), that you can have class loading
issues with SFL4J as well: Of course, I won't have any, if there is a
single binding in a shared class loader. But that's mainly the case
because SFL4J is currently less common than JCL. In other words, as
soon as SFL4J bindings will start to be part of any major or minor
component, they will start to override each other, causing all kind of
trouble.
I agree that class loading issues with SFL4J will be simpler (because
it's architecture in that aspect is much simpler), but nothing more.
Jochen
--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
-- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
My guess: Nokia E50)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
