Mark Thomas wrote:
Ate Douma wrote:
When Pluto needs to "aggregate" the content of this TestPortlet, it
invokes it render(PortletRequest, PortletResponse) method using a
"cross-context" call from the Pluto web application to the "test" web
application.
The TestPortlet.render method receives the PortletRequest object (as
loaded from the Pluto WEB-INF/lib) and invokes its
PortletRequest.getPortletPreferences() method. If the PortletPreferences
class hasn't been accessed yet before, this will cause the ClassLoader
of PortletRequest, being the Pluto webapp ClassLoader, to now load the
PortletPreferences class.
But, because the current ContextClassLoader is the "test" webapp
ClassLoader, LogFactory will lookup the logger implementation from the
"test" webapp...
With as result that logging output for the PortletPreferences class will
end up in the target as specified by the "test" webapp, not in the one
(as expected) as configured for the Pluto webapp.
I have seen similar issues in Tomcat's internal logging with
java.util.logging, log4j and commons-logging. Why will this be any
different with slf4j?
Because sfl4j does not use the ContextClassLoader to determine the logger
instance but compile-time binding.
Exactly the reason why CL doesn't work and slf4j does.
I think using slf4j for Tomcat internal logging would solve this too.
The only possible workaround I could come up with was extending
LogFactory itself and temporarily switching/enforcing the current
ContextClassLoader to that of the class itself, but obviously we didn't
even consider that as a real option.
In Tomcat, the issue was (mainly) log objects for internal components
being created and loaded by a web application class loader. This was a
particular issue for Jasper, the JSP engine, as it interacts quite
closely with web apps. We solved this by ensuring that the logs were
created during Tomcat start.
Sure, that will work *if* you manage to prime/pre-load all loggers upfront.
For a webserver that might be doable (for its internal libraries), but for an embeddable component like a portletcontainer and definitely
for a highly configurable and extendable portal like Jetspeed that would put too much runtime overhead and an indeterminable configuration
nightmare for the end users/integrators.
Would a similar solution not work for Pluto? Use a
ServletContextListener to create your log instances when the portlet
container web appilcation starts?
And start scanning and preloading all classes from WEB-INF/classes and
WEB-INF/lib?
Replacing CL with slf4j is by far a more transparent and easier solution than
that.
Ate
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
