You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Ate Douma (JIRA)" <je...@portals.apache.org> on 2006/06/08 16:33:30 UTC
[jira] Resolved: (JS2-541) Log initialization failures when
deploying on Websphere 6.0.2.x
[ http://issues.apache.org/jira/browse/JS2-541?page=all ]
Ate Douma resolved JS2-541:
---------------------------
Resolution: Fixed
Fixed (although maybe better called a workaround for the nasty WAS 6.0.2.x classloader bug)
> Log initialization failures when deploying on Websphere 6.0.2.x
> ---------------------------------------------------------------
>
> Key: JS2-541
> URL: http://issues.apache.org/jira/browse/JS2-541
> Project: Jetspeed 2
> Type: Improvement
> Components: Components Core
> Versions: 2.1-dev
> Environment: Ubuntu 6.0.6, Websphere Application Server 6.0.2.x
> Reporter: Ate Douma
> Assignee: Ate Douma
> Priority: Blocker
> Fix For: 2.1, 2.1-dev
>
> Websphere 6.0.2.x has a mighty annoying classloader bug which prevents the JetspeedServlet to initialize.
> When Websphere bootstraps a web application, it uses *not* the (properly) created web application classloader (configured with PARENT_LAST)
> but its own com.ibm.ws.bootstrap.ExtClassLoader (which defaults to PARENT_FIRST) for class initializing (<clinit>) the servlet.
> Note: the correct web application classloader *is* used to initialize the servlet itself (method init(ServletConfig)), but not the static
> class initialization (<clinit>).
> And, starting (again) the portal through the WAS admin console, exposes a similar classloader bug. This time, not the bootstrap.ExtClassLoader
> is set as context ClassLoader but the *console* app classloader during class initialization!
> We currently have two static initialized Commons Logging Log members defined in the JetspeedServlet.
> Furthermore, through the jetspeed-webapp-logging component, we setup a custom Log implementation (IsolatedLog4JLogger) which Commons Logging
> picks up from the commons-logging.properties resource file (contained within the jetpeed-webapp-logging jar).
> But, WebSphere 6.0.2.x (and maybe even 6.0 but I haven't checked that one) also provides such a commons-logging.properties resource contained within
> the ws-commons-logging.jar from the globally shared lib directory.
> In it, it defines:
> org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger
> Note: this wasn't the case yet in WAS 5!
> Now, because of the above described classloader bug (e.g. a PARENT_FIRST bootstrap classloader) during static initialization of the JetspeedServlet,
> Commons Logging will *not* see the commons-logging.properties resource as provided by our jetspeed-webapp-logging jar but load it from the global
> ws-commons-logging.jar.
> Problem:
> org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log
> at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:532)
> at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:272)
> at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:246)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:395)
> at org.apache.jetspeed.engine.JetspeedServlet.<clinit>(JetspeedServlet.java:61)
> ... 25 more
> A quick workaround would be removing the Log definition from the commons-logging.properties in ws-commons-logging.jar.
> Better yet: IBM should fix this classloader bug!
> But luckily (in this situation) the JetspeedServlet can be modified such that this problem won't occurr:
> I'm going to move the initialization of the static Log instances in JetspeedServlet to the init(ServletConfig).
> When that method is invoked by WAS, it is done with the proper context ClassLoader and Log initialization uses our IsolatedLog4JLogger again.
> And then, after I fixed this, another classloader problem popped up!
> JetspeedServlet also implements HttpSessionListener which it uses for closure of PortalStatistics logging when a user logs out.
> Now, it turns out WAS 6.0.2.x calls the Servlet.destroy() method *before* calling sessionDestroyed(HttpSessionEvent) for existing sessions!
> It seemingly does so (again) with an incorrect context classloader.
> In our JetspeedServlet.sessionDestroyed() implementation we try to access the PortalStatistics component from the SpringComponentManager.
> But, as the JetspeedEngine (and thus the ComponentManager) have already shutdown because JetspeedServlet.destroy() has already been called,
> Spring is going to reload its configuration. And, as it wants to logs some info messages doing that, its going to (re)initialize Commons Logging
> again too (which also already was shutdown through the Log4JConfigurator ContextListener).
> And there it is again, same exception as shown above: Jdk14Logger does not implement Log :(
> So, I've also modified the JetspeedServlet.sessionDestroyed() method which will skip PortalStatistics closure logging when the destroy() method
> has been called already.
> A last remark for anyone wanting to deploy a Jetspeed based portal on WAS and has dependencies on xerces, xalan and xml-apis for its
> portlet applications (just as Jetspeed itself has).
> You need to move these three jars (as well as the other already required shared libs) inside the ear *besides* the war files, define a Class-Path
> entry in each war file META-INF/MANIFEST.MF referencing these "shared" libs, and remove these three jars from your war WEB-INF/lib folder.
> This is standard shared library ear file packaging, check the J2EE docs for further information.
> And finally: make sure to change the default WAS Class Loader Mode to PARENT_LAST for your portal ear *and* each of its contained (portlet) web applications.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org