Menu
▾
▴
[JBoss-dev] [ jboss-Bugs-870942 ] Classloader problem with ear file
|
From: SourceForge.net <no...@so...> - 2004-01-28 16:44:32
|
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 sco...@jb... ---------------------------------------------------------------------- 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> sco...@jb... ---------------------------------------------------------------------- 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 |