Bugs item #734736, was opened at 2003-05-08 16:25
Message generated for change (Comment added) made by adrianprice
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=734736&group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: G French (misterfrench)
Assigned to: Scott M Stark (starksm)
Summary: EAR classloading error
Initial Comment:
OS: Windows 2000 Professional
JDK: Sun 1.3.1
JBoss version: 3.2.1 with Tomcat 4.1.24
ClassCast exceptions experienced when deploying the
attached testcase EAR.
Investigations have found that if I include xercesImpl.jar,
xml-apis.jar and log4j.jar in the manifest class-path of
the EJB jar in the EAR, I get the exceptions in the
server log attached when JBoss attempts to deploy the
WAR inside the EAR. Removing the entries makes the
exceptions disappear.
----------------------------------------------------------------------
Comment By: Adrian Price (adrianprice)
Date: 2003-10-14 13:07
Message:
Logged In: YES
user_id=580837
I have found the exact same problem myself, but didn't
realise the exceptions disappear if you remove the Class-Path
manifest attributes. I solved the problem by removing
xercesImpl.jar and xml-apis.jar from the .ear entirely.
According to the J2EE 1.3 spec., app. servers are required to
provide a full implementation of JAXP 1.1, so it shouldn't be a
problem unless there's some pressing reason why you
absolutely have to use Xerces. (Even if the app. server does
not natively support Xerces, it should be possible to configure
its JAXP parser registry to do so.)
----------------------------------------------------------------------
Comment By: G French (misterfrench)
Date: 2003-05-09 11:38
Message:
Logged In: YES
user_id=774499
Attached is the output of ListJar.
Here are some more remarks:
1. I need to run the EARs with the scoped classloader as we
will have multiple EARs with potentially different versions of
the same classes running in the same JBoss.
2. I don't want to have a separate web container as part of the
EAR - the EAR should run anywhere. Equally I should not
have to replace JBoss's libraries with my own versions. The
EAR should be a self-contained application.
3. As for the log4j CCE, I still get this when I use the
DOMConfigurator to load my own log4j.xml elsewhere on the
filesystem before I initialise the logger in TestImpl - as I would
assume that with the EAR scoped classloader I would be
using the unconfigured log4j shipped in the EAR
static
{
DOMConfigurator.configureAndWatch
("C:/log4j.xml");
}
private static final Logger logger = Logger.getLogger
(TestImpl.class);
again I suspect that this CCE is related to the jaxp CCE.
4. All this appeared to work fine in 3.0.7.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2003-05-09 01:06
Message:
Logged In: YES
user_id=175228
So this ear wants to load classes from its deployment before
the server classpath. The web container has static
references to the jaxp classes that were bound when the
jbossweb.sar was deployed. By redeploying the jaxp classes
in the scoped ear you are replacing classes that are used at
the server component level. To do this you would have to
deploy the web container in addition to your ear to ensure a
consistent class loader space. If I remove the ear level
soping then this example starts fine and the ejb is uable.
In this case the deployment level classes are ignored.
16:57:07,635 INFO [jbossweb] Started
WebApplicationContext[/test.war,TestServlet]
16:57:07,855 INFO [jbossweb] TestServlet: webapp:
TestServlet loading
16:57:07,865 INFO [jbossweb] TestServlet:
***************************************
JNDI tree:
java:comp
|
+---UserTransaction [Value]
|
+---env [Context]
|
+---security [Context]
|
+---realmMapping [Value]
|
+---subject [Value]
|
+---securityMgr [Value]
|
+---security-domain [Value]
|
+---test-value [Value]
|
+---deployment-id [Value]
***************************************
16:57:07,915 INFO [jbossweb] TestServlet: Val from lookup:
16:57:07,935 INFO [jbossweb] Registered
jboss.web:Jetty=0,JBossWebApplicationContext=0,context=/test.war,name=jsp
16:57:07,945 INFO [jbossweb] Registered
jboss.web:Jetty=0,JBossWebApplicationContext=0,context=/test.war,name=default
16:57:07,955 INFO [jbossweb] Registered
jboss.web:Jetty=0,JBossWebApplicationContext=0,context=/test.war,name=invoker
16:57:07,965 INFO [jbossweb] Registered
jboss.web:Jetty=0,JBossWebApplicationContext=0,context=/test.war,name=TestServl
et
16:57:07,995 INFO [jbossweb] Registered
jboss.web:Jetty=0,JBossWebApplicationContext=0,context=/test.war,HashSessionMan
ager=0
16:57:07,995 INFO [jbossweb] successfully deployed
file:/C:/usr/JBoss3.2/jboss-3.2/build/output/jboss-3.2.2beta/server/
default/tmp/deploy/server/default/deploy/test2.ear/13.test2.ear-contents/test.war
to /test.war
16:57:08,046 INFO [EARDeployer] Started J2EE application:
file:/C:/usr/JBoss3.2/jboss-3.2/build/output/jboss-3.2.2beta/
server/default/deploy/test2.ear
16:57:08,046 INFO [MainDeployer] Deployed package:
file:/C:/usr/JBoss3.2/jboss-3.2/build/output/jboss-3.2.2beta/server/
default/deploy/test2.ear
16:57:08,086 INFO [URLDeploymentScanner] Started
16:57:08,156 INFO [MainDeployer] Deployed package:
file:/C:/usr/JBoss3.2/jboss-3.2/build/output/jboss-3.2.2beta/server/
default/conf/jboss-service.xml
16:57:08,166 INFO [Server] JBoss (MX MicroKernel)
[EMAIL PROTECTED]@] Started in 11s:437ms
17:02:47,113 INFO [TestImpl] TestBean loading.....
17:02:47,113 INFO [TestImpl] *** TestImpl() ***
17:02:47,123 INFO [TestImpl] ejbCreate()
17:02:47,133 INFO [STDOUT] *** DO SOMETHIG ***
So if you have to deploy an ear that uses its own copies of
the xml parser, log4j, and another other libraries that
JBoss itself uses, you have to deploy those components as
part of your application. The CCE coming from the web
container is due to the war deployer being tthe point at
which the parsing of the war descriptors occurs. If this was
moved to a sperate class that was created in the thread
context of the war this probably would work so that is
something I'll look into.
The cause of the CCE coming from the log4j layer is due to
the log4j layer going out and finding a log4j.xml visable
through the class loaders. This is finding the server
conf/log4j.xml config and trying to recreate the log4j setup
in the scoped ear. The DailyRollingFileAppender class does
not exist in the scoped ear so it is loaded from the ear
parent class loader repository. This class has already been
linked against the org.apache.log4j.Appender class that
exists at this level and conflicts with the Appender
reloaded in the scoped ear level. To address this you need a
log4j.xml in the ear scope.
Right now the xml parser issue probably requires that you
replace the JBoss server version with the one you need
unless you can configure a seperate web container as part of
your ear deployment.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2003-05-08 17:11
Message:
Logged In: YES
user_id=175228
Take the attached ListLjar.java source and run the ListJar
class on the full test.ear and add that as an attachment so
I can be sure of the structure. This will show any manifest
classpaths.
----------------------------------------------------------------------
Comment By: G French (misterfrench)
Date: 2003-05-08 16:53
Message:
Logged In: YES
user_id=774499
OK, take 3, could not upload EAR in its entirety (2Mb) so
I''ve attached a skeleton EAR which will need the following
files added to it:
>From xerces 2.3.0
xercesImpl.jar
xml-apis.jar
>From log4j 1.2.8
log4j.jar
Add these file to
1. test.ear top level dir
2. test.war (inside EAR) WEB-INF/lib
----------------------------------------------------------------------
Comment By: G French (misterfrench)
Date: 2003-05-08 16:31
Message:
Logged In: YES
user_id=774499
Sorry, forgot to attach test EAR.
This EAR should deploy with exceptions similar to those in
attached server log. Remove the manifest class-path inside
the EJB jar (test.jar) and the EAR will deploy OK.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=734736&group_id=22866
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
