commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Bollinger <thinma...@yahoo.com>
Subject Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Date Fri, 24 Apr 2009 21:48:59 GMT
Hi Ate,

I'm glad your switch to SLF4J is doing what you need it to do, and I am in no way trying to
persuade you to change course there.  I do think, however, that the problem of classes loading
required resources via the wrong ClassLoader could easily manifest in webapp / portlet components
other than the logging system, thus I respectfully suggest that "trying to get rid of the
ContextClassLoader use for *only* the logging" may be short sighted.   I would not be so bold
as to insist that the proxy solution must necessarily be useful or appropriate for you.  Nevertheless,
the fact that the portlet container needs to so carefully manage which context ClassLoader
is used, where, and when would make me nervous if it were my responsibility.  You seem comfortable
with that, so I'll say no more on the topic.

Best Wishes,

John



Ate Douma wrote:
> While your example proxy solution is nice enough by itself, imo its way too much over-engineering
for the issue at hand.
> We're trying to get rid of the ContextClassLoader use for *only* the logging, not add
more overhead to it!
> And, in practice this solution wouldn't work for us anyway as there are other cross-context
invocation usages where we
> *need* the ContextClassLoader of the caller, like when marshalling and unmarshalling
complex PortletEvent payload (using
> JAXB) provided by the Portlet Application to be dispatched across potentially even other
Portlet Applications (all this
> managed and coordinated from the Portal/container web app). The PortletContainer (we)
know when to use the
> ContextClassLoader and when not. An all-encompassing proxy solution adds too much unnecessary
overhead and actually
> blocks the usage of the real ContextClassLoader when its needed.
>
> We just needed the least intrusive and most straightforward solution available and wrapping
or patching CL simply doesn't
> fit that bill.


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