Geronimo
  1. Geronimo
  2. GERONIMO-3894

java.lang.NoClassDefFoundError: org/jdom/Parent using JDOM 1.0

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.1
    • Fix Version/s: None
    • Component/s: core, webservices
    • Security Level: public (Regular issues)
    • Labels:
      None
    • Environment:

      OS : windows 2003

      Description

      We've got a problem using jDOM 1.0 with geronimo 2.0.1.

      Just using the following method : XPath.newInstance(String) we encounter the following error message.

      Caused by: java.lang.NoClassDefFoundError: org/jdom/Parent
      at org.jaxen.jdom.JDOMXPath.(JDOMXPath.java:91)
      at org.jdom.xpath.JaxenXPath.setXPath(JaxenXPath.java:281)
      at org.jdom.xpath.JaxenXPath.(JaxenXPath.java:99)
      at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
      at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
      at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
      at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
      at org.jdom.xpath.XPath.newInstance(XPath.java:137)

      The class Parent is present in the jdom jar which is located in the lib directory of our web application. (Such as the jaxen beta 9 jar)

      We have seen on JIRA that there is a similar problem :

      AXIS2-3413 : Cannot use JDOM within Axis2 (java.lang.NoClassDefFoundError: org/jdom/Parent)

      But don't really understand which solution is to be applied.

      There is obviously a conflict with jaxen jar but what should we do exactly?

      There are no Sub-Tasks for this issue.

        Activity

        Hide
        Jean-Jacques Parent added a comment -

        Out of date

        Show
        Jean-Jacques Parent added a comment - Out of date
        Hide
        Jean-Jacques Parent added a comment -

        Can close this issue. Quite old, out of date

        Show
        Jean-Jacques Parent added a comment - Can close this issue. Quite old, out of date
        Hide
        Jean-Jacques Parent added a comment -

        First of all, thank you for your quick reply.
        We have applied your solution and it works now. We encoutered some similar problems, which were also due to jar conflicts. So we had to add another hidden class as follow :

        <hidden-classes>
        <filter>org.jaxen</filter>
        <filter>org.apache.axis2</filter>
        </hidden-classes>

        If I understand well, by default the jar are always loaded from the parent classloader and not from the WEB-INF/lib directory of our web application (such as weblogic does for example). I find this quite dangerous because when I will migrate to Geronimo 2.0.2 which may contains new versions of jar, I will have to check that my application still work with those versions.
        The solution will be to hide (as above) all the jar of our web application and which are shipped with Geronimo. This may be quite forcing to do.
        Another solution may be to use the inverseClassloading flag of the 'Resource Adapter Geronimo Deployment Plan' if this is its purpose.
        What is the best practise?

        Show
        Jean-Jacques Parent added a comment - First of all, thank you for your quick reply. We have applied your solution and it works now. We encoutered some similar problems, which were also due to jar conflicts. So we had to add another hidden class as follow : <hidden-classes> <filter>org.jaxen</filter> <filter>org.apache.axis2</filter> </hidden-classes> If I understand well, by default the jar are always loaded from the parent classloader and not from the WEB-INF/lib directory of our web application (such as weblogic does for example). I find this quite dangerous because when I will migrate to Geronimo 2.0.2 which may contains new versions of jar, I will have to check that my application still work with those versions. The solution will be to hide (as above) all the jar of our web application and which are shipped with Geronimo. This may be quite forcing to do. Another solution may be to use the inverseClassloading flag of the 'Resource Adapter Geronimo Deployment Plan' if this is its purpose. What is the best practise?
        Hide
        Kevan Miller added a comment -

        Create a Geronimo deployment plan (assuming you don't already have one). Like the following

        <?xml version="1.0" encoding="UTF-8"?>
        <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1" xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1" xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1">
        <dep:environment>
        <dep:moduleId>
        <dep:groupId>org.mygroup</dep:groupId>
        <dep:artifactId>MyApp</dep:artifactId>
        <dep:version>1.0</dep:version>
        <dep:type>car</dep:type>
        </dep:moduleId>
        <!--
        Don't load jaxen classes from parent ClassLoaders.
        -->
        <hidden-classes>
        <filter>org.jaxen</filter>
        </hidden-classes>
        </dep:environment>
        </web-app>

        Assumin you've called this file NoJaxen.xml, you can deploy using:

        ./bin/deploy.sh <YourApp.war> NoJaxen.xml

        Show
        Kevan Miller added a comment - Create a Geronimo deployment plan (assuming you don't already have one). Like the following <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1" xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1" xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1"> <dep:environment> <dep:moduleId> <dep:groupId>org.mygroup</dep:groupId> <dep:artifactId>MyApp</dep:artifactId> <dep:version>1.0</dep:version> <dep:type>car</dep:type> </dep:moduleId> <!-- Don't load jaxen classes from parent ClassLoaders. --> <hidden-classes> <filter>org.jaxen</filter> </hidden-classes> </dep:environment> </web-app> Assumin you've called this file NoJaxen.xml, you can deploy using: ./bin/deploy.sh <YourApp.war> NoJaxen.xml
        Hide
        Manu T George added a comment -

        Have you tried using hidden-classes to hide the conflicting classes in the parent classloaders? JDOM is shipped with G. So by default the JDOM jar loaded will be from the parent classloader and will not pick up the jaxen jar in your application. Try hiding org.jdom and org.jaxen as I understand you package both in your application

        Show
        Manu T George added a comment - Have you tried using hidden-classes to hide the conflicting classes in the parent classloaders? JDOM is shipped with G. So by default the JDOM jar loaded will be from the parent classloader and will not pick up the jaxen jar in your application. Try hiding org.jdom and org.jaxen as I understand you package both in your application

          People

          • Assignee:
            Unassigned
            Reporter:
            Jean-Jacques Parent
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development