8 Replies Latest reply on May 30, 2003 4:52 PM by jherbers

    JBoss 3.2 jar conflicts (castor, xalan)

    jherbers Newbie

      Our app deploys fine with 3.0.x (and other AppServers) It is an EAR files with several dependent jars included, such as castor, xalan, xerces. However, with 3.2 the following errors occur when classes in these jars are used.

      Note that 3.0.x and 3.2 both contain xalan.jar and castor.jar in their lib dirs. But while 3.0.x doesn't have a problem with our EAR also containing these jars, 3.2 does. With castor, we can remove the jar file from JBoss and we're ok. However, we can't seem to remove xalan.jar or JBoss itself fails. Instead we have to put our (newer) version in JB's classpath - this prevents it from complaining about the copy in the EAR. What changed in 3.2 and is this a bug to be fixed?

      java.lang.LinkageError: duplicate class definition: org/apache/xpath/functions/FuncQname
      ...
      java.lang.LinkageError: duplicate class definition: org/exolab/castor/mapping/loader/MappingLoader

        • 1. Re: JBoss 3.2 jar conflicts (castor, xalan)
          Bernd Zeitler Expert

          You can use this part for configuring JBoss to use an own loader repository for e.g. every ear (when used in jboss-app.xml):
          [pre]
          <jboss-app>
          <loader-repository>yam.com:loader=bean1.ear
          <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
          </loader-repository>
          </jboss-app>
          [/pre]

          The name of the repository must be unique and the config tag says JBoss to change the behaviour of classloaders by first asking the child for resources, then delegating to the parent.

          Greetings,
          Frito

          • 2. Re: JBoss 3.2 jar conflicts (castor, xalan)
            jherbers Newbie

            Thanks for the suggestion. I tried it with 3.2.1 (jetty) and got the following.

            2003-05-23 11:30:38,895 ERROR [org.jboss.deployment.MainDeployer] could not start deployment: file:/D:/jboss-3.2.1/server/default/tmp/deploy/server/default/deploy/Tcdc.ear/22.Tcdc.ear-contents/Tcdc.war
            java.lang.Error: java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl
            at org.mortbay.xml.XmlParser.(XmlParser.java:65)
            at org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:326)
            at org.mortbay.j2ee.J2EEWebApplicationContext.start(J2EEWebApplicationContext.java:85)
            at org.jboss.jetty.JBossWebApplicationContext.start(JBossWebApplicationContext.java:89)
            at org.jboss.jetty.Jetty.deploy(Jetty.java:331)
            at org.jboss.jetty.JettyService.performDeploy(JettyService.java:242)

            • 3. Re: JBoss 3.2 jar conflicts (castor, xalan)
              Bernd Zeitler Expert

              Are you using a "tuned" version of JBoss, since this works for me with 3.2.0 (and I think I tried this with 3.2 HEAD, too)?
              My ear contains xerces.jar and castor.jar .

              Greetings,
              Frito

              • 4. Re: JBoss 3.2 jar conflicts (xerces, castor, xalan)
                jherbers Newbie

                Frito, thanks for the response. I don't think we are using a "tuned" version - I'm just dropping the EAR into the default server deploy dir, I don't think I've done anything else special to my installation.

                Obviously including the jboss-app.xml files as you described is having an effect, because with it included the EAR won't even deploy (whereas before I didn't get errors until a client caused code that references one of these jars to be run).

                I don't know much about how JBoss does XML processing (and I'm not a xerces expert either). But I don't see a Xerces jar in its lib dir, so could the problem be that JB has its own implementation of SaxParser that is not compatible with Xerces, thus giving the ClassCastException?

                • 5. Re: JBoss 3.2 jar conflicts (castor, xalan)
                  Jon Barnett Master

                  Strange. You should be seeing a xercesImpl.jar in the topmost lib directory of the distribution.

                  Maybe I'm missing something here, but can JBoss use the newer xalan and castor distributions? That is, have the APIs changed so that you can't replace JBoss's copies with the new ones?

                  • 6. Re: JBoss 3.2 jar conflicts (castor, xalan)
                    Jon Barnett Master

                    On 3.2.0, tried with xalan 2.5.0 distribution - doesn't like the xercesImpl or xml-apis being replaced (in top most lib). Also deleted the xml-apis floating around in my instance libs. Replaced xalan in server/default/lib with xalan 2.5.0 (2.5 Mb file !!!).

                    Seems to work ok. Deployed range of beans, wars and ears and they worked ok. Does that help any?

                    • 8. Re: JBoss 3.2 jar conflicts (castor, xalan)
                      jherbers Newbie

                      Jonlee: You're right, Xerces.impl is in JB's top-level lib dir, I had only been looking in server\default\lib. From what you're finding, it's takes a manual process to configure JBoss 3.2 to allow the use of newer xalan, castor and xerces jars by our apps. Bummer!