[
https://issues.apache.org/jira/browse/PLUTO-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma updated PLUTO-553:
----------------------------
Description:
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).
was:
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 no 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).
> 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.
