Apologies for joining this thread so late in the discussion...

Can you detail how you are packaging up your EARs (I seem to recall they
were EARs as opposed to WARs)... If you have not tried it, you might see if
moving your jars in the EAR into the WLS proprietary APP-INF/lib dir
(exactly akin to WEB-INF/ in WARs) and see if that helps any.

-d

-----Original Message-----
From: Jacob Kjome [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 30, 2004 1:47 PM
To: Log4J Users List
Subject: RE: Class loading issues using WLS 8.1?

One other thing to remember is not to put endorsed libraries in WEB-INF/lib.

That is, libraries that are part of the JDK or J2EE.  I believe Tomcat
solves this by actively not loading endorsed packages in WEB-INF/lib.
However, I wouldn't count on other appservers doing the same.

Rules of thumb...

1.  Never put an XML parser in WEB-INF/lib.  Put it in the appserver's
classpath.  You should be using the standard API's anyway and shouldn't need
to worry about which implementation you are using.

2.  Never put stuff like activation.jar, JDBC drivers, etc... in
WEB-INF/lib. 
These are endorsed packages and should be loaded by the application server.


Jake

Quoting Ceki G�lc� <[EMAIL PROTECTED]>:

> 
> There are many articles explaining classloaders. Just google for 
> "classloader".
> 
> Here is one relevant result:
> 
> http://www.javaworld.com/javaworld/javaqa/2003-06/01-qa-0606-load.html
> 
> 
> To make matters worse, certain application servers set context and 
> current classloaders to different ClassLoader instances that have the 
> same classpaths and yet are not related as a delegation parent and 
> child. Take a second to think about why this is particularly 
> horrendous. Remember that the classloader that loads and defines a 
> class is part of the internal JVM's ID for that class. If the current 
> classloader loads a class X that subsequently executes, say, a JNDI 
> lookup for some data of type Y, the context loader could load and 
> define Y. This Y definition will differ from the one by the same name 
> but seen by the current loader. Enter obscure class cast and loader
constraint violation exceptions.
> 
> 
> 
> At 05:24 PM 8/30/2004, you wrote:
> >No, I was not aware of this.  I thought that if I have two jars, one 
> >loaded via the system class loader and one load via the web-app class 
> >loader, the web application would look to its loaded version and 
> >there would not be a problem.  I would like to understand this a 
> >little better.  Could you explain?
> >
> >Joshua
> >
> >
> >
> >-----Original Message-----
> >From: Ceki G�lc� [mailto:[EMAIL PROTECTED]
> >Sent: Monday, August 30, 2004 11:16 AM
> >To: Log4J Users List
> >Subject: RE: Class loading issues using WLS 8.1?
> >
> >
> >
> >Are you aware of the fact that two classes loaded by distinct 
> >classloaders are considered incompatible even if the classes are bitwise
identical?
> >
> >
> >At 04:47 PM 8/30/2004, you wrote:
> > >Ceki,
> > >
> > >I do have a copy of xereces.jar and xerecesImpl.jar in my lib dir.  
> > >Here
> >are
> > >the other jars are in my WEB-INF/lib dir:
> > >
> > >activation.jar
> > >commons-beanutils.jar
> > >commons-collections.jar
> > >commons-digester.jar
> > >commons-fileupload.jar
> > >commons-lang.jar
> > >commons-logging.jar
> > >commons-validator.jar
> > >CorbaIDL.jar
> > >dom.jar
> > >jakarta-oro.jar
> > >jaxen-full.jar
> > >jaxp-api.jar
> > >jdbc2_0-stdext.jar
> > >jstl.jar
> > >log4j-1.2.8.jar
> > >mail.jar
> > >MetafileRenderer.jar
> > >OB405.jar
> > >OBBiDir.jar
> > >OBEvent.jar
> > >OBIMR.jar
> > >OBNaming.jar
> > >OBProperty.jar
> > >OBTest.jar
> > >OBTime.jar
> > >OBUtil.jar
> > >rasapp.jar
> > >rascore.jar
> > >reportsourcefactory.jar
> > >ReportTemplate.jar
> > >sax.jar
> > >saxpath.jar
> > >serialization.jar
> > >standard.jar
> > >struts-el.jar
> > >struts.jar
> > >webreporting.jar
> > >WebReportWizard.jar
> > >xalan.jar
> > >xerces.jar
> > >xercesImpl.jar
> > >
> > >Joshua
> > >
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: Ceki G�lc� [mailto:[EMAIL PROTECTED]
> > >Sent: Monday, August 30, 2004 10:41 AM
> > >To: Log4J Users List
> > >Subject: RE: Class loading issues using WLS 8.1?
> > >
> > >
> > >
> > >As Yoav suggested earlier, it looks like a versioning problem 
> > >caused by multiple copies of the JAXP API.
> > >
> > >JDK 1.4 already ships with JAXP API + a JAXP parser. Thus, there 
> > >must be another copy of JAXP API somewhere else. Do you have a copy 
> > >of xerces or crimson lying around? Where did you put the log4j.jar 
> > >file? Could you
> > list >the adjacent jar files?
> > >
> > >At 04:28 PM 8/30/2004, you wrote:
> > > >Ceki,
> > > >
> > > >It is JDK jdk141_05 which comes with WLS 8.1.3.  When I start 
> > > >WLS, I see Java HotSpot(TM) Client VM Version 1.4.1_05-b01 
> > > >though.  Anything else I
> > >can
> > > >do to help?
> > > >
> > > >Joshua
> > >
> > >--
> > >Ceki G�lc�
> > >
> > >       For log4j documentation consider "The complete log4j manual"
> > >       ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
> > >
> > >
> > >
> > >-------------------------------------------------------------------
> > >-- To unsubscribe, e-mail: 
> > >[EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >This communication, including attachments, is for the exclusive use 
> > >of addressee and may contain proprietary, confidential or 
> > >privileged information. If you are not the intended recipient, any 
> > >use, copying, disclosure, dissemination or distribution is strictly 
> > >prohibited. If you are not the intended recipient, please notify 
> > >the sender immediately by return email and delete this 
> > >communication and destroy
> > all >copies.
> > >
> > >
> > >-------------------------------------------------------------------
> > >-- To unsubscribe, e-mail: 
> > >[EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >--
> >Ceki G�lc�
> >
> >       For log4j documentation consider "The complete log4j manual"
> >       ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >This communication, including attachments, is for the exclusive use 
> >of addressee and may contain proprietary, confidential or privileged 
> >information. If you are not the intended recipient, any use, copying, 
> >disclosure, dissemination or distribution is strictly prohibited. If 
> >you are not the intended recipient, please notify the sender 
> >immediately by return email and delete this communication and destroy 
> >all copies.
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> 
> --
> Ceki G�lc�
> 
>       For log4j documentation consider "The complete log4j manual"
>       ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
> 
> 
> 
> ---------------------------------------------------------------------
> 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]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to