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? > 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. Would a similar solution not work for Pluto? Use a ServletContextListener to create your log instances when the portlet container web appilcation starts? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
