I think this is indeed very close to what happened. It sounds reasonable. The problem persisted, even when I removed from the JVM classpath the JRun lib directory that contained the JRun provided log4j classes (the only log4j jar that was left in the classpath was the one in the Jetspeed 1.5 WEB-INF/lib directory). This means that the server was loading the JRun built-in classes regardless of what I was putting in the JVM classpath. It seems that the only way to override this in JRun is to put libraries in the JRUN_HOME/servers/lib directory. The problem with this is that these jars will affect all JRun servers and not just the one you are interested in.
One of the reasons why we need to use JRun in my organization is that we have old ColdFusion apps that we need to maintain. I know that the cfusion server that comes with JRun has its' own log4j jar in its' WEB-INF/lib (yes, yet another one!). Now that I've placed the Jetspeed log4j jar in the global JRUN_HOME/servers/lib directory, I'm wondering how it's going to affect the ColdFusion apps. I'll give an update when I find out. -----Original Message----- From: Scott T. Weaver [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 11:15 AM To: Jetspeed Users List Subject: Re: Running Jetspeed 1.5 on JRun4 I think what is happening here is what you tend to see in the standard JBoss classloader . JRun probably loaded some of the log4j classes at startup from its log4j jar. Now Jetspeed 2 required those classes but instead of the JRun classloaders loading new ones from the WEB-INF/lib it just used the ones it already loaded from its server classloader. Next what probably happened is J2 tried to load up a couple more log4j classes that had not been loaded yet in any classloader yet. So those classes where loaded from the WEB-INF/lib jar. Finally when the app tried to mix these classes, a classcast was thrown. Even if the two jars were identical, this would have happened because for 2 classes to be considered the same they have to be loaded from the same classloader. If they were not loaded from the same classloader a CCE is thrown even if they are, in all other ways, identical. This is just a theory though, and I could be totally wrong ;) Stathis, George wrote: >Figured out the problem. It was indeed a conflict between the log4j >versions, but somehow, the Jetspeed application was not picking up the >log4j jar in its own WEB-INF\lib directory, but rather, the log4j >classes in the JRUN_HOME\lib\oem-xdoclet.jar. > >The problem was rectified by taking the Jetspeed log4j jar out of the >jetspeed WEB-INF\lib and putting it in JRUN_HOME\servers\lib. This is a >bit unorthodox though. Shouldn't the application specific jars in >WEB-INF\lib be overriding the other classpaths? > >Anyway, thanks to Scott for taking the time to help out! > > >-----Original Message----- >From: Stathis, George [mailto:[EMAIL PROTECTED] >Sent: Thursday, October 14, 2004 10:47 AM >To: 'Jetspeed Users List' >Subject: RE: Running Jetspeed 1.5 on JRun4 > > >Thank you for the prompt reply. I'm running J1.5 by the way. I just >tried your suggestion and the problem persists in the exact same way >(same messages). > >Looking at the classpath available to the JRun JVM, I see that there >are two versions of log4j *in addition* to the one in Jetspeed itself. >They both come built-in JRun. One is in: > >%JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib >\log4 >j.jar > >The other in: > >%JRUN_HOME%\lib\oem-xdoclet.jar > >which contains open source libraries, one of which is log4j. Both >directories above are in the JVM classpath. For a test, I put back the >log4j jar in jetspeed/WEB-INF/lib and *removed* the two directories >above from the class path. Same error. > >Then, I removed the log4j jar from jetspeed/WEB-INF/lib again, and also >left out the two directories above from the classpath. Different error: > >(!) NOTICE: Turbine: init() failed: java.lang.NoClassDefFoundError: >org/apache/log4j/LogManager > >Ahaa! "NoClassDefFoundError" Now I know that log4j is completely out of >the classpath. > >I re-tested now by putting back into the classpath each jar one by one. >Results: > >The >%JRUN_HOME%\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib >\log4 >j.jar is not being picked up. If it's the only one in the classpath, I still >get a "NoClassDefFoundError" error. But both the >%JRUN_HOME%\lib\oem-xdoclet.jar and the Jetspeed log4j.jar cause the exact >same error: > >(!) NOTICE: Turbine: init() failed: java.lang.VerifyError: (class: >org/apache/log4j/LogManager, method: <clinit> signature: ()V) >Incompatible argument to function > >Either there is yet another log4j jar somewhere (not likely since I get >a "NoClassDefFoundError" already), or the problem is somewhere else. > >I will keep experimenting. If there are any other ideas or I'm missing >something, please, someone let me know. > > > >-----Original Message----- >From: Scott T. Weaver [mailto:[EMAIL PROTECTED] >Sent: Thursday, October 14, 2004 10:00 AM >To: Jetspeed Users List >Subject: Re: Running Jetspeed 1.5 on JRun4 > > >Hi George, > >Looks like a version conflict in the version of log4j included with J2 >and the one JRun appears to be using. Try removing the log4j jar from >the jetspeed/WEB-INF/lib directory. > >Stathis, George wrote: > > > >>A few more details: >> >>1) Our JRun installation came with ColdFusion MX 6.1, so a bunch of >>ColdFusion classes are in the classpath. >> >>2) When starting the server that houses the Jetspeed 1.5 application, >>the following JetspeedLoggingService related error appears in the JRun >>Launcher >>log: >> >>Starting Apache Jetspeed Portal/1.5 >> >>(!) NOTICE: init >>(!) NOTICE: ServiceBroker: LoggingService enabled. >>(!) NOTICE: Turbine: init() failed: java.lang.VerifyError: (class: >>org/apache/log4j/LogManager, method: <clinit> signature: ()V) >>Incompatible argument to function >> at >>org.apache.jetspeed.services.logging.JetspeedLogFactoryService.getLogge >>r(Jet >>speedLogFactoryService.java:168) >> at >>org.apache.jetspeed.services.logging.JetspeedLoggingService.<clinit>(Jetsp e >> >> >e > > >>dLoggingService.java:59) >> at java.lang.Class.forName0(Native Method) >> at java.lang.Class.forName(Class.java:141) >> at >>org.apache.turbine.services.BaseInitableBroker.getInitableInstance(Base >>Init >> >> >a > > >>bleBroker.java:257)rethrown as >>org.apache.turbine.services.InstantiationException: Failed to >>instantiate org.apache.jetspeed.services.logging.JetspeedLoggingService >> at >>org.apache.turbine.services.BaseInitableBroker.getInitableInstance(Base >>Init >> >> >a > > >>bleBroker.java:295) >> at >>org.apache.turbine.services.BaseInitableBroker.initClass(BaseInitableBr >>oker >> >> >. > > >>java:145) >> at >>org.apache.turbine.services.BaseServiceBroker.initService(BaseServiceBr >>oker >> >> >. > > >>java:139) >> at >>org.apache.turbine.services.TurbineServices.initPrimaryServices(Turbine >>Serv >> >> >i > > >>ces.java:204) >> at org.apache.turbine.Turbine.init(Turbine.java:247) >> at javax.servlet.GenericServlet.init(GenericServlet.java:258) >> at >>jrun.servlet.WebApplicationService.loadServlet(WebApplicationService.ja >>va:1 >> >> >2 > > >>43) >> at >>jrun.servlet.WebApplicationService.preloadServlets(WebApplicationServic >>e.ja >> >> >v > > >>a:790) >> at >>jrun.servlet.WebApplicationService.postStart(WebApplicationService.java >>:297 >> >> >) > > >> at >>jrun.deployment.DeployerService.initModules(DeployerService.java:711) >> at >>jrun.deployment.DeployerService.createWatchedDeployment(DeployerService >>.jav >> >> >a > > >>:242) >> at jrun.deployment.DeployerService.deploy(DeployerService.java:430) >> at >>jrun.deployment.DeployerService.handleEvent(DeployerService.java:381) >> at >>jrunx.kernel.JRunServiceDeployer.fireEvent(JRunServiceDeployer.java:710) >> at >>jrunx.kernel.JRunServiceDeployer.deployServices(JRunServiceDeployer.jav >>a:11 >> >> >1 > > >>) >> at >>jrunx.kernel.DeploymentService.loadServices(DeploymentService.java:46) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja >>va:3 >> >> >9 > > >>) >> at >>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso >>rImp >> >> >l > > >>.java:25) >> at java.lang.reflect.Method.invoke(Method.java:324) >> at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >> at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >> at jrunx.kernel.JRun.startServer(JRun.java:575) >> at jrunx.kernel.JRun.<init>(JRun.java:493) >> at jrunx.kernel.JRun$1.run(JRun.java:346) >> at java.security.AccessController.doPrivileged(Native Method) >> at jrunx.kernel.JRun.start(JRun.java:343) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja >>va:3 >> >> >9 > > >>) >> at >>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso >>rImp >> >> >l > > >>.java:25) >> at java.lang.reflect.Method.invoke(Method.java:324) >> at jrunx.kernel.JRun.invoke(JRun.java:180) >> at jrunx.kernel.JRun.main(JRun.java:168) >> >>Server default ready (startup time: 13 seconds) >> >>-----Original Message----- >>From: Stathis, George [mailto:[EMAIL PROTECTED] >>Sent: Wednesday, October 13, 2004 10:56 AM >>To: '[EMAIL PROTECTED]' >>Subject: Running Jetspeed 1.5 on JRun4 >> >> >>I haven't seem any messages specific to JRun4 problems, so I have to >>ask myself. Is anyone running Jetspeed 1.5 on JRun4 (with the latest >>service pack, "Update 4", installed)? >> >>I have downloaded the Jetspeed 1.5 WAR file and have have successfully >>deployed it on Tomcat 5. Deploying it on JRun4 expands the WAR file >>fine, but when trying to browse to the portal's front page, I get an >>HTTP 500 "The page cannot be displayed" error. Looking at the JRun >>logs, I find the following error: >> >> >>10/13 10:39:32 error ServiceBroker: unknown service PoolService >>requested >>org.apache.turbine.services.InstantiationException: ServiceBroker: >>unknown service PoolService requested at >>org.apache.turbine.services.BaseServiceBroker.getServiceInstance(BaseS >>ervic >> >> >e > > >>Broker.java:354) >>at >>org.apache.turbine.services.BaseServiceBroker.getService(BaseServiceBro >>ker. >> >> >j > > >>ava:296) >>at >>org.apache.turbine.util.RunDataFactory.putRunData(RunDataFactory.java: >>2 >>26) >>at org.apache.turbine.Turbine.doGet(Turbine.java:643) >>at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) >>at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >>at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91) >>at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42) >>at >>jrun.servlet.JRunRequestDispatcher.invokeNext(JRunRequestDispatcher.java:4 4 >> >> >9 > > >>) >>at >>jrun.servlet.JRunRequestDispatcher.forwardInvoke(JRunRequestDispatcher. >>java >> >> >: > > >>418) >>at >>jrun.servlet.JRunRequestDispatcher.forward(JRunRequestDispatcher.java: >>1 >>75) >>at jrun.jsp.runtime.JRunPageContext.forward(JRunPageContext.java:349) >>at jrun.jsp.tags.Forward.doit(Forward.java:14) >>at jrun.jsp.tags.RequestDispatchTag.doEndTag(RequestDispatchTag.java:47) >>at jrun__index2ejspa._jspService(jrun__index2ejspa.java:58) >>at jrun.jsp.runtime.HttpJSPServlet.service(HttpJSPServlet.java:43) >>at jrun.jsp.JSPServlet.service(JSPServlet.java:119) >>at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91) >>at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42) >>at >>jrun.servlet.JRunRequestDispatcher.invokeNext(JRunRequestDispatcher.java:4 4 >> >> >9 > > >>) >>at >>jrun.servlet.JRunRequestDispatcher.forwardInvoke(JRunRequestDispatcher. >>java >> >> >: > > >>418) >>at >>jrun.servlet.JRunRequestDispatcher.forward(JRunRequestDispatcher.java: >>1 >>75) >>at jrun.servlet.file.FileServlet.service(FileServlet.java:306) >>at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91) >>at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42) >>at >>jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:249) >>at >>jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:527) >>at jrun.servlet.http.WebService.invokeRunnable(WebService.java:168) >>at >>jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:4 5 >> >> >7 > > >>) >>at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66) >> >>I'm not sure where to get started debugging here. I'm sure it's a JRun >>problem rather than a Jetspeed problem (and I will post for help on >>the Macormedia forums too), but I just wanted to see if people have >>any quick suggestions here. >> >>Thank you in advance for your time. >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> >> >> > > > > -- "Great minds discuss ideas. Average minds discuss events. Small minds discuss people." - Admiral Hyman Rickover ******************************************* * Scott T. Weaver * * <[EMAIL PROTECTED]> * * <http://www.einnovation.com> * * -------------------------------------- * * Apache Jetspeed Enterprise Portal * * Apache Pluto Portlet Container * * * * OpenEditPro, Website Content Management * * <http://www.openedit.org> * ******************************************* --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
