8 Replies Latest reply on May 7, 2009 7:23 PM by Avor Nadal

    xercesImpl conflict: How to isolate an EAR deployment

    Avor Nadal Newbie

      Good nights:

      I've been "googling" all the afternoon trying to fix a conflict between a version of "xercesImpl" which I use in an EAR file and the one employed by JBoss. After reading some forums and Wikis I've came to the conclusion that I need to isolate my EAR deployment in order to use its own and exclusive scope.

      One of the documents which I've checked firstly is one located in the JBoss Wiki: http://www.jboss.org/community/wiki/ClassLoadingConfiguration.

      I'm using JBoss v. 4.2.2 (I can't use the newest version because I'm messed into a work in progress) and have tested 2 steps without success:

      1 - Trying to configure the "ear-deployer.xml" to isolate EVERY application.
      2 - Trying to configure the "jboss-app.xml" to use an exclusive loader repository.

      Am I doing anything wrong? Thank you very much in advance.
      Am I doing anything wrong.

        • 1. Re: xercesImpl conflict: How to isolate an EAR deployment
          jaikiran pai Master

          #2 is what i do for my apps. Can you post your configs? And also the entire exception stacktrace? Also list the jars that you are packaging and the place where they are within the EAR.

          While posting logs or xml content or code, please remember to wrap it in a code block by using the Code button in the message editor window. Please use the Preview button to ensure that your post is correctly formatted.

          • 2. Re: xercesImpl conflict: How to isolate an EAR deployment
            Avor Nadal Newbie

            jaikiran: First of all, thank you for your quick answer. It's nice to have such help.

            I've tested all this using a very simple EAR file whose structure is as follows:

            trax.ear
            |
            |----- lib
            | |----- xercesImpl.jar
            |
            |----- META-INF
            | |----- application.xml
            | |----- jboss-app.xml
            | |----- MANIFEST.MF
            |
            |----- trax-ejb.jar
             |----- META-INF
             |----- jboss.xml
             |-----MANIFEST.MF
            


            The EAR package can be downloaded directly from http://www.negora.com/file/trax.ear .

            This is the trace of the exception returned by JBoss:

            21:26:01,984 WARN [ServiceController] Problem creating service jboss.j2ee:service=EJB3,module=trax-ejb.jar
            org.jboss.xb.binding.JBossXBRuntimeException: Failed to create a new SAX parser
             at org.jboss.xb.binding.UnmarshallerFactory$UnmarshallerFactoryImpl.newUnmarshaller(UnmarshallerFactory.java:100)
             at org.jboss.ejb3.metamodel.JBossDDObjectFactory.parse(JBossDDObjectFactory.java:76)
             at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:45)
             at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
             at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:383)
            
             at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:327)
             at org.jboss.ejb3.Ejb3Module.createService(Ejb3Module.java:77)
             at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:260)
             at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:243)
             at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
            
             at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
             at java.lang.reflect.Method.invoke(Method.java:585)
             at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
             at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
             at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
             at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
             at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
             at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
             at $Proxy0.create(Unknown Source)
             at org.jboss.system.ServiceController.create(ServiceController.java:330)
             at org.jboss.system.ServiceController.create(ServiceController.java:273)
             at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
             at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
             at java.lang.reflect.Method.invoke(Method.java:585)
             at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
             at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
             at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
             at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
             at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
             at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
             at $Proxy33.create(Unknown Source)
             at org.jboss.ejb3.EJB3Deployer.create(EJB3Deployer.java:492)
             at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
             at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
             at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
             at java.lang.reflect.Method.invoke(Method.java:585)
             at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
             at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
             at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
             at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
             at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
             at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
             at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
             at org.jboss.wsf.container.jboss42.DeployerInterceptor.create(DeployerInterceptor.java:76)
             at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
             at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
             at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
             at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
             at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
             at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
             at $Proxy34.create(Unknown Source)
             at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
             at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
             at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
             at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
             at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
             at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
             at java.lang.reflect.Method.invoke(Method.java:585)
             at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
             at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
             at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
             at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
             at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
             at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
             at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
             at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
             at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
             at $Proxy9.deploy(Unknown Source)
             at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
             at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:610)
             at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
             at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
             at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
            Caused by: org.jboss.xb.binding.JBossXBException: Failed to create a new SAX parser
             at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.<init>(SaxJBossXBParser.java:96)
             at org.jboss.xb.binding.UnmarshallerImpl.<init>(UnmarshallerImpl.java:55)
             at org.jboss.xb.binding.UnmarshallerFactory$UnmarshallerFactoryImpl.newUnmarshaller(UnmarshallerFactory.java:96)
             ... 72 more
            Caused by: java.lang.ClassCastException: org.apache.xerces.parsers.XIncludeAwareParserConfiguration
             at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
             at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
             at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source)
             at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source)
             at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
             at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.<init>(SaxJBossXBParser.java:92)
             ... 74 more
            
            


            It seems that despite declaring an exclusive class scope in the "jboss-app.xml" file of the EAR package, JBoss "overwrites" its own "xercesImpl.jar" with the one included in the package, and thus, the conflict to read the following XMLs contained in "trax.ear".

            If you rename or remove the "lib" directory, everything works fine, obviously.

            About the specifications of my programming environment, I'm using:

            - Windows XP - Service Pack 3
            - Java Runtime Environment 6 - Update 13
            - Java Development Kit 5 - Update 16
            - JBoss Application Server v. 4.2.2
            - Library Xerces-J v. 2.9.1

            Thanks a lot ;) .

            • 3. Re: xercesImpl conflict: How to isolate an EAR deployment
              jaikiran pai Master

               

              Caused by: java.lang.ClassCastException: org.apache.xerces.parsers.XIncludeAwareParserConfiguration

              I haven't looked at the contents of the xercesImpl.jar (yet). But most of the times, its not just that single jar that needed in the classloader scoping. You will have to place the other jars which the xercesImpl.jar depends on, too in the EAR/lib folder. I don't have the exact list of required jars right now. But most of them are jars which contain the xml parsing classes. Give it a try by including the other dependent jars that you know.


              • 4. Re: xercesImpl conflict: How to isolate an EAR deployment
                Avor Nadal Newbie

                jaikiran: Very good point and a big mistake from me... Although it hasn't worked :/ .

                The package of Xerces-J includes the following JARs:

                resolver.jar
                serializer.jar
                xercesImpl.jar
                xml-apis.jar
                


                Before testing your idea, I thought that the lack of dependency libraries would return an exception of type "NoClassDefFound". Or maybe no errors even, since there wasn't any file in execution (it was just the deploying phase).

                However, after reading your message twice, I think I got you and realized that maybe JBoss was combining the use of my version of "xercesImpl.jar" with non-matching versions of the rest of JARs. Unfortunately, I've added them too and I still get that error.

                Something which is even more odd: I've decided to remove that JARs and use exactly the sames names and versions which are included in JBoss, in "lib/endorsed". Indeed, I've just copied and pasted them in my "lib" folder. And guess what? The same error occurs!!!

                So this clarifies that it's not a matter of versions... By the way, the files are:

                serializer.jar
                xalan.jar
                xercesImpl.jar
                


                I've also tried to change the name of "lib" and modify the "META-INF/MANIFEST.MF" to point to the renamed folder ("liv" in this case). But it seems not to work:

                Manifest-Version: 1.0
                Class-Path: liv/serializer.jar liv/xalan.jar liv/xercesImpl.jar liv/mylib.jar
                
                
                


                To check if it had worked, I've added a personal library (mylib.jar) to use this in a JSP file. No errors returned were in the deployment, but the JSP failed because it didn't find "mylib.jar".

                After "googling" a little more I've seen that some servers, including JBoss, were already supporting the tag inside of a tag , in the "application.xml" file:

                 <module>
                 <java>liv/serializer.jar</java>
                 </module>
                 <module>
                 <java>liv/xalan.jar</java>
                 </module>
                 <module>
                 <java>liv/xercesImpl.jar</java>
                 </module>
                


                The libraries have been loaded properly, but the deployment error came back. So, in other words, it doesn't matter if you just put "xercesImpl.jar" in the default directory ("lib") or you use an unofficial one and refer to it in "application.xml".

                • 5. Re: xercesImpl conflict: How to isolate an EAR deployment
                  Avor Nadal Newbie

                  By the way, the forum seems to have "ate" the tags of one of my last comments, he he he. I meant "were already supporting the tag 'java' inside of a tag 'module'".

                  • 6. Re: xercesImpl conflict: How to isolate an EAR deployment
                    Avor Nadal Newbie

                    Something else... I've also tried the tag *library-directory* in "application.xml" to specify a different name than "lib", but it seems not to be recognized by this version of JBoss:

                    <library-directory>lib</library-directory>
                    


                    I'm gonna look for more information on the Internet and, if I'm not lucky, I guess I'll just use

                    • 7. Re: xercesImpl conflict: How to isolate an EAR deployment
                      Avor Nadal Newbie

                      More information... I've checked this line in "deploy/jboss-web.deployer/META-INF/jboss-service.xml":

                      <attribute name="UseJBossWebLoader">false</attribute>
                      


                      I know, it has nothing to do with the deployment of EAR files, but has made me discover why in another past project I could use "xercesImpl.jar" inside of a web application without conflicts: Because it's using an independent class loader (the one from Tomcat) instead of the JBoss one.

                      So the question now is... Is it impossible to use any library which is already used by JBoss for itself? Will they be in conflict forever?

                      If so, then I guess I'll have to get used to employ the versions used by every version of JBoss and get resigned to it ;) .

                      • 8. Re: xercesImpl conflict: How to isolate an EAR deployment
                        Avor Nadal Newbie

                        Well, well... Sorry for so many messages, but since I can't edit mine, I've to add one after another and so on :P .

                        I've found a solution to use the last version of that JARs and without JBoss complaining because of it.

                        First of all, I've realized that the 3 JARs included in "lib/endorsed" are just the content of the "Xalan-J" package from Apache (which includes "xercesImpl.jar" of course).

                        I already got in my local repository the last version of Xalan. So I've just made a backup of "endorsed" and made a new one with the content of the last Xalan. I've turned on JBoss, and everything has worked fine.

                        Another workaround which I've discovered is to change the value of the JBOSS_ENDORSED_DIRS environment variable in several of the "bin/*.sh" or "bin/*.bat" files and make it point to a personal directory which include the most recent JARs of Xalan-J.

                        The only problem of doing all this is that you won't be able to use different versions of Xerces at the same time.

                        Fortunately I've tried to duplicate in my project more JARs used by JBoss and they don't cause any problem. Even different versions of "xalan.jar" or "serializer.jar" can be used isolated in every project.

                        So, summarizing a lot, this problem seems to be exclusive of "xercesImpl.jar". And, sincerely, I doubt that I can't live with only 1 version of it. I'll use a common.

                        If you have any alternative idea about this, let me know ;) .