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.
