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

    JBoss 3.2 jar conflicts (castor, xalan)

    jherbers

      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)
          frito

          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

            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)
              frito

              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

                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)
                  jonlee

                  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)
                    jonlee

                    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?

                    • 7. Re: JBoss 3.2 jar conflicts (castor, xalan)
                      frito

                      Oops, posted in the wrong place, but works for both, I think ;-)

                      http://www.jboss.org/modules/bb/index.html?module=bb&op=viewtopic&t=

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

                        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!