No problem ;-) I appreciate any effort to help. -----Original Message----- From: Dan Moore [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 10:31 AM To: Jetspeed Users List Subject: RE: Running Jetspeed 1.5 on JRun4
Hi George, I entirely misread your problem. Twice. If the wrong version of the log4j classes are being picked up, it sounds like you've found the solution. Sorry for the confusion. Dan --- "Stathis, George" <[EMAIL PROTECTED]> wrote: > I'm pretty sure this is not a Jetspeed issue. I think it's JRun not > prioritizing properly where each web application should be loading > its' classes from (i.e. jars in WEB-INF/lib should take priority over > JRun jars). > Tomcat for example has 5 loaders that take care of this > prioritization. > > Dan, you want me to try putting log4j.properties in WEB-INF/classes or > did you mean the log4j jar? > > > -----Original Message----- > From: Dan Moore [mailto:[EMAIL PROTECTED] > Sent: Friday, October 15, 2004 10:13 AM > To: Jetspeed Users List > Subject: RE: Running Jetspeed 1.5 on JRun4 > > > Hi George, > > This isn't a Jetspeed issue, I don't think. > > I'm pretty sure that WEB-INF/lib is not itself added to any webapp's > classpath. Each jar inside WEB-INF/lib is, but WEB-INF/lib itself is > not. > > Did you try putting log4j.properties in WEB-INF/classes? This > directory is in the classpath. > > Dan > > PS A typical webapp classpath will look like: > WEB-INF/classes:WEB-INF/lib/a.jar:WEB-INF/lib/b.jar:WEB-INF/lib/c.jar > > Section SRV.9.5 of the servlet 2.3 spec says > "The web application classloader must load classes from the WEB-INF/ > classes directory first, and then from library JARs in the WEB-INF/lib > directory." > > --- "Stathis, George" <[EMAIL PROTECTED]> 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>(Je >tspe > > 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 > === message truncated === --------------------------------------------------------------------- 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]
