[
https://issues.apache.org/jira/browse/PLUTO-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701283#action_12701283
]
John Bollinger edited comment on PLUTO-553 at 4/21/09 5:53 PM:
---------------------------------------------------------------
Is this not a problem whenever the target portlet method loads resources via
the classloader -- config files, images, etc.? I think it's important for code
running in the target portlet (edit: or container) to be able to rely on the
context classloader being an appropriate one to use to access the portlet's
resources, but it seems you're saying that this is not a safe assumption in
Pluto.
I'm not saying Pluto shouldn't switch to SLF4J -- I have no opinion on that. I
do think there is a deeper issue here than logging, however.
was (Author: jcbollinger):
Is this not a problem whenever the target portlet method loads resources
via the classloader -- config files, images, etc.? I think it's important for
code running in the target portlet to be able to rely on the context
classloader being an appropriate one to use to access the portlet's resources,
but it seems you're saying that this is not a safe assumption in Pluto.
I'm not saying Pluto shouldn't switch to SLF4J -- I have no opinion on that. I
do think there is a deeper issue here than logging, however.
> commons-logging unsuited for cross-context webapplication invocation usage -
> migrating to slf4j
> -----------------------------------------------------------------------------------------------
>
> Key: PLUTO-553
> URL: https://issues.apache.org/jira/browse/PLUTO-553
> Project: Pluto
> Issue Type: Bug
> Components: general, portlet container
> Affects Versions: 2.0.0
> Reporter: Ate Douma
> Assignee: Ate Douma
> Priority: Blocker
> Fix For: 2.0.0
>
>
> The benefits and downsides of using Apache Commons Logging already has been
> discussed endlessly on the web, but last Thursday I've encountered a really
> nasty problem which imo finally nails it as unsuited for usage with portals.
> The problem is commons-logging using the ContextClassLoader to determine the
> current LogFactory and logger.
> As a Portal/PortletContainer (e.g. pluto-container) depend on cross-context
> invocation, determining the LogFactory for a portal/portletcontainer class
> while being cross-context invoked from a portlet application,
> this means commons-logging will use the invoking portlet application its
> classloader instead of the expected/needed classloader of the
> portal/portletcontainer...
> Now, this could be "fixed" by either wrapping each and every cross-context
> callback into the portal/portletcontainer and temporarily setting the current
> ContextClassLoader or wrapping commons-logging itself,
> but imo the LogFactory "resolving" solution applied by commons-logging is
> fundamentally problematic for *our* purpose.
> I won't go as far as saying commons-logging is bad and should never be used,
> but for portals/portletcontainers and cross-context application handling it
> just doesn't fit.
> Now, where does that leave us?
> Looking at alternatives, I think there are only a few:
> a) only using Java(4) logging
> b) using Apache Log4J directly
> c) switch to slf4j (http://www.slf4j.org)
> Of the above options, a and b forces end users (integrators) of Pluto to
> leverage the same logging solution which imo is too restricted:
> - Java logging is too limited and a nuisance to use (personal opinion)
> - Log4J is great but not everyone enjoys it, and for instance Logback (LGPL)
> is building up a lot of users because of its (supposedly) higher performance
> and lesser overhead
> AFAIK, that leaves only slf4j which, although not ASF based, has a compatible
> license and is being adopted already a lot by other ASF projects.
> The benefit of slf4j is also (besides "fixing" the commons-loggings problems)
> that it supports gradual "migration" from commons-logging through its
> jcl-over-slf4j solution.
> During this weekend, I've spend some time doing a local migration of both
> Pluto 2.0 and Jetspeed-2.2 to slf4j to see how much trouble that would be and
> if I would encounter unexpected problems.
> I can now attest that this migration is mostly "painless", slf4j even has a
> migrator tool which does most of the hard work (code wise).
> Of course, there was some "pain" in the maven dependencies migration but I
> could complete that in a reasonably short time (manually) as well.
> After all this, the JSR-286 TCK (of course) still completed successfully and
> logging still works just as fine.
> As I see no real alternative for solving this imo *blocking* issue, I think
> finalizing this migration to sfl4j is the only reasonable resolution.
> I'll also send a message to the Pluto dev list soliciting further feedback on
> this, but if nobody objects I intend to commit my changes for this soon (I
> will create a separate issue for migrating Jetspeed-2.2 to slf4j).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
