Bugs item #870942, was opened at 2004-01-05 06:54
Message generated for change (Comment added) made by starksm
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866
Category: JBossMX
Group: v3.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Steve Wolfangel (swolfangel)
Assigned to: Scott M Stark (starksm)
Summary: Classloader problem with ear file
Initial Comment:
Hello,
I have an ear file that contains 2 stateless session
beans and all the 3rd party jars required by the beans.
The 3rd party jars contain older jdom classes than the
jdom jar included in the jboss lib dir. I have a unique
classloader setup (in the jboss-app.xml file) but I am
having problems with jdom. It is finding the jboss jdom
classes instead of the ones included in the ear.
when I change the jboss-app.xml file to contain the
following lines:
<jboss-app>
<loader-repository>
com.metamatrix:loader=MM.ear
<loader-repository-
config>java2ParentDelegation=false</loader-repository-
config>
</loader-repository>
</jboss-app>
I get a NoClassDefFoundError.
java.lang.NoClassDefFoundError: java/sql/SQLException
This class is in the rt.jar file in the jdk!
I was under the impression that setting
java2ParentDelegation to false meant that if the class
was not found using the local classloader then the
parent classloader would be called.
In a nutshell, when I have java2ParentDelegation set to
true, I get the jdom problem, when I have
java2ParentDelegation set to false I am unable to see
classes that are in the rt.jar file.
Here is the output when starting the server.
[Server] Starting JBoss (MX MicroKernel)...
[Server] Release ID: JBoss [WonderLand] 3.2.3 (build:
CVSTag=JBoss_3_2_3 date=200311301445)
[Server] Home Dir: D:\mm40\jb32\server\jboss
[Server] Home URL: file:/D:/mm40/jb32/server/jboss/
[Server] Library URL: file:/D:/mm40/jb32/server/jboss/lib/
[Server] Patch URL: null
[Server] Server Name: metamatrix
[Server] Server Home Dir: D:\mm40\jb32
\server\jboss\server\metamatrix
[Server] Server Home URL:
file:/D:/mm40/jb32/server/jboss/server/metamatrix/
[Server] Server Data Dir: D:\mm40\jb32
\server\jboss\server\metamatrix\data
[Server] Server Temp Dir: D:\mm40\jb32
\server\jboss\server\metamatrix\tmp
[Server] Server Config URL:
file:/D:/mm40/jb32/server/jboss/server/metamatrix/conf/
[Server] Server Library URL:
file:/D:/mm40/jb32/server/jboss/server/metamatrix/lib/
[Server] Root Deployment Filename: jboss-service.xml
[Server] Starting General Purpose Architecture (GPA)...
[ServerInfo] Java version: 1.4.2,Sun Microsystems Inc.
[ServerInfo] Java VM: Java HotSpot(TM) Client VM
1.4.2-b28,Sun Microsystems Inc.
[ServerInfo] OS-System: Windows XP 5.1,x86
----------------------------------------------------------------------
>Comment By: Scott M Stark (starksm)
Date: 2004-01-28 08:44
Message:
Logged In: YES
user_id=175228
This has been fixed by excluding the scoped class loaders
that are not using parent first delegation from locating
resources outside of thier classpath. The fix is in for the
3.2.4RC1 release.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2004-01-23 13:58
Message:
Logged In: YES
user_id=175228
No you should not be able to override java.* system classes
other than through vm specific means. Its a security issue
and the final ClassLoader.defineClass will not let you do
it. The xerces classes are not in the java.* package namespace.
----------------------------------------------------------------------
Comment By: Martin Handwerker (mhandwerker)
Date: 2004-01-23 13:19
Message:
Logged In: YES
user_id=952324
The jboss classloader should not be special-casing java.*, or
any other package names (Scott-- my interpretation of your
last comment is that you think it should).
Metamatrix probably shouldn't be redistributing java.sql
classes with their ear, but if they do, those classes SHOULD
override the system java.sql classes when referenced from
the EAR.
Scott mentioned that there is a test-case for replacing the
XML parser with a different version of Xerces. We are doing
just that with our EAR, and are finding that jboss is trying to
use our Xerces classes when parsing our descriptors, even
though we have java2ParentDelegation set to false in a jboss-
app.xml file.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2004-01-23 12:37
Message:
Logged In: YES
user_id=175228
This is due to the use of scoped class loading that wants to
load classes from ear before the parent class loader, and
the inclusion of java.sql package classes in the ear:
+- metamatrix-server.jar (archive)
...
| +- java/sql/Package.html
| +- java/sql/ParameterMetaData.class
| +- java/sql/Savepoint.class
classes in the java.* should not be able to override the
system classes, but this should not be preventing the load
of system classes so this is a bug.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2004-01-15 04:56
Message:
Logged In: YES
user_id=175228
There is no zip file with the ucl.log attached to this bug,
only the server.log. If the zip file exceeds the attachment
size limit send it to [EMAIL PROTECTED]
----------------------------------------------------------------------
Comment By: Steve Wolfangel (swolfangel)
Date: 2004-01-06 08:39
Message:
Logged In: YES
user_id=541224
Is there any thing else I can do to help troubleshoot this
problem?
----------------------------------------------------------------------
Comment By: Steve Wolfangel (swolfangel)
Date: 2004-01-05 09:09
Message:
Logged In: YES
user_id=541224
Attached log.zip file containing ucl.log and server.log
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2004-01-05 08:40
Message:
Logged In: YES
user_id=175228
Next step, add the following to the conf/log4j.xml and send me
the resulting server.log and ucl.log zipped up as the
ucl.log can
be large:
<appender name="UCL" class="org.apache.log4j.FileAppender">
<param name="File"
value="${jboss.server.home.dir}/log/ucl.log"/>
<param name="Append" value="false"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern"
value="[%r,%c{1},%t] %m%n"/>
</layout>
</appender>
<category name="org.jboss.mx.loading" additivity="false">
<priority value="TRACE" class="org.jboss.logging.XLevel"/>
<appender-ref ref="UCL"/>
</category>
[EMAIL PROTECTED]
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2004-01-05 08:33
Message:
Logged In: YES
user_id=175228
Yes, and there is a testcase in 3.2 for replacing the xml
parser with a different version of xerces for example, using
this approach. The problem with overriding the various xml
related classes is that these are used all over and not all
contexts are correctly limiting the scope of the classes
they use. Presumably this is the case for the jdom usage.
----------------------------------------------------------------------
Comment By: Steve Wolfangel (swolfangel)
Date: 2004-01-05 07:41
Message:
Logged In: YES
user_id=541224
Replacing the jdom.jar file got me past this problem. I am still
interested in finding the correct solution since there is a
chance I could have similar problems in the future.
Am I correct by assuming that by setting up my own
classloader and setting java2ParentDelegation to false in the
jboss-app file is the correct approach?
----------------------------------------------------------------------
Comment By: Steve Wolfangel (swolfangel)
Date: 2004-01-05 07:25
Message:
Logged In: YES
user_id=541224
I added the server.log file that contains the complete stack
trace of the NoClassDefFound error.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2004-01-05 07:19
Message:
Logged In: YES
user_id=175228
The jdom.jar is only used by the XMBean parsing so as an
immeadiate workaround just replace the top lib/jdom.jar with
your version.
Also, show the full stack trace for the NoClassDefFoundError
on lookup of SQLException.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
