Commons Configuration
  1. Commons Configuration
  2. CONFIGURATION-88

[configuration] ClassNotFoundException on Sun App Server

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Operating System: Windows XP
      Platform: PC

      Description

      When used in an EJB application deployed on Sun app server 8.1 (platform edition
      8.1 build b28-beta), ConfigurationFactory throws a java.lang.ClassNotFoundException:
      org.apache.commons.configuration.Configuration.

      Sun includes Digester in at least one of the jars included with the platform,
      appserv-rt.jar, so presumably Digester is being loaded by the System
      classloader. This makes Digester unable to find classes loaded by the EJB
      classloader (in this case, classes in configuration-1.0.jar) unless Digester's
      useContextClassLoader variable is set to true.

      This patch modifies ConfigurationFactory to set useContextClassLoader to true on
      the digester.

      Index: ConfigurationFactory.java
      ===================================================================
      RCS file:
      /home/cvspublic/jakarta-commons/configuration/src/java/org/apache/commons/configuration/ConfigurationFactory.java,v
      retrieving revision 1.20
      diff -u -w -b -r1.20 ConfigurationFactory.java
      — ConfigurationFactory.java 23 Dec 2004 18:42:25 -0000 1.20
      +++ ConfigurationFactory.java 9 Feb 2005 20:22:18 -0000
      @@ -152,8 +152,12 @@
      // awareness must be configured before the digester rules are
      loaded.
      configureNamespace(digester);
      }
      +
      + digester.setUseContextClassLoader (true);
      +
      // Put the composite builder object below all of the other objects.
      digester.push(builder);
      +
      // Parse the input stream to configure our mappings
      try
      {

        Activity

        Mike Colbert created issue -
        Hide
        Mike Colbert added a comment -

        Stack trace ...

        java.lang.ClassNotFoundException:
        org.apache.commons.configuration.Configuration
        at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
        at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:243)
        at org.apache.commons.digester.Rule.end(Rule.java:276)
        at org.apache.commons.digester.Digester.endElement(Digester.java:1058)
        at
        com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:585)
        at
        com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:221)
        at
        com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:839)
        at
        com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1563)
        at
        com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:341)
        at
        com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:828)
        at
        com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:758)
        at
        com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
        at
        com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1178)
        at org.apache.commons.digester.Digester.parse(Digester.java:1567)
        at
        org.apache.commons.configuration.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:157)

        Show
        Mike Colbert added a comment - Stack trace ... java.lang.ClassNotFoundException: org.apache.commons.configuration.Configuration at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(ClassLoader.java:289) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:243) at org.apache.commons.digester.Rule.end(Rule.java:276) at org.apache.commons.digester.Digester.endElement(Digester.java:1058) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:585) at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:221) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:839) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1563) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:341) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:828) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:758) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1178) at org.apache.commons.digester.Digester.parse(Digester.java:1567) at org.apache.commons.configuration.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:157)
        Hide
        Oliver Heger added a comment -

        Mike,

        I am a bit reluctant about this patch because I am unsure whether it has any
        undesired side effects. Did you check if all unit tests run with your modification?

        Did you evaluate other options to solve your problem, e.g. including the correct
        version of digester in your ear and setting the classpath property in the
        manifest of your ejb-jars?

        Oliver

        Show
        Oliver Heger added a comment - Mike, I am a bit reluctant about this patch because I am unsure whether it has any undesired side effects. Did you check if all unit tests run with your modification? Did you evaluate other options to solve your problem, e.g. including the correct version of digester in your ear and setting the classpath property in the manifest of your ejb-jars? Oliver
        Hide
        Mike Colbert added a comment -

        Hi Oliver,

        I ran the unit tests with and without the patch; TestXMLConfiguration failed in
        the same way both times at testLoad. So, I'm unable to tell at this time if the
        patch affects the unit tests. This is using code from CVS.

        Regarding other options, I'm open to alternatives. I am already packaging the
        correct jars in the EAR and setting the classpath in the ejb-jar manifest. This
        doesn't solve the problem, though, due to the classloader delegation model.
        Since Digester is already loaded by the System classloader, it will not be
        loaded by any child classloaders, such as the EJB classloader.

        Again, I'm using code from CVS. Does this make any difference? I'm a little
        confused about whether to use CVS or SVN here. CVS doesn't look seem as up to date.

        Show
        Mike Colbert added a comment - Hi Oliver, I ran the unit tests with and without the patch; TestXMLConfiguration failed in the same way both times at testLoad. So, I'm unable to tell at this time if the patch affects the unit tests. This is using code from CVS. Regarding other options, I'm open to alternatives. I am already packaging the correct jars in the EAR and setting the classpath in the ejb-jar manifest. This doesn't solve the problem, though, due to the classloader delegation model. Since Digester is already loaded by the System classloader, it will not be loaded by any child classloaders, such as the EJB classloader. Again, I'm using code from CVS. Does this make any difference? I'm a little confused about whether to use CVS or SVN here. CVS doesn't look seem as up to date.
        Hide
        Oliver Heger added a comment -

        Mike,

        we (the whole jakarta commons) switched from CVS to SVN recently. There have
        been minor changes in the meantime (especially in the build.xml), thats probably
        the reason why the unit tests fail. You can checkout the newest version of
        configuration using

        svn checkout
        http://svn.apache.org/repos/asf/jakarta/commons/proper/configuration/trunk

        Oliver

        Show
        Oliver Heger added a comment - Mike, we (the whole jakarta commons) switched from CVS to SVN recently. There have been minor changes in the meantime (especially in the build.xml), thats probably the reason why the unit tests fail. You can checkout the newest version of configuration using svn checkout http://svn.apache.org/repos/asf/jakarta/commons/proper/configuration/trunk Oliver
        Hide
        Emmanuel Bourg added a comment -

        The code has been migrated to SVN recently, you can ignore the code in CVS.

        I'm +1 for the change suggested by Mike, I haven't tested it but it makes sense.
        If this issue comes back later we can easily add a way to configure the
        classloader used by the ConfigurationFactory.

        Show
        Emmanuel Bourg added a comment - The code has been migrated to SVN recently, you can ignore the code in CVS. I'm +1 for the change suggested by Mike, I haven't tested it but it makes sense. If this issue comes back later we can easily add a way to configure the classloader used by the ConfigurationFactory.
        Hide
        Oliver Heger added a comment -

        If the unit tests run, I am fine as well.

        I was wondering if it makes sense to get rid off digester as a core dependency
        anyway. The XML files processed by configuration factory are quite simple and
        digester does not earn us that much. I think parsing these files by hand using
        SAX would not be too complicated.

        Oliver

        Show
        Oliver Heger added a comment - If the unit tests run, I am fine as well. I was wondering if it makes sense to get rid off digester as a core dependency anyway. The XML files processed by configuration factory are quite simple and digester does not earn us that much. I think parsing these files by hand using SAX would not be too complicated. Oliver
        Hide
        Emmanuel Bourg added a comment -

        Well why not, but that may prevent us from doing more complex things with
        ConfigurationFactory in the future. Digester is also used by
        XMLPropertiesConfiguration, a simple SAX parser would be good enough there.

        Show
        Emmanuel Bourg added a comment - Well why not, but that may prevent us from doing more complex things with ConfigurationFactory in the future. Digester is also used by XMLPropertiesConfiguration, a simple SAX parser would be good enough there.
        Hide
        Oliver Heger added a comment -

        Or even cooler, we could use XMLConfiguration in ConfigurationFactory to parse
        the definition file. Then we could use the whole Configuration API to access the
        properties and could do wild things, too. Just a thought, but I enjoy such
        recursive stuff!

        Show
        Oliver Heger added a comment - Or even cooler, we could use XMLConfiguration in ConfigurationFactory to parse the definition file. Then we could use the whole Configuration API to access the properties and could do wild things, too. Just a thought, but I enjoy such recursive stuff!
        Hide
        Simon Kitching added a comment -

        (In reply to comment #8)
        > Or even cooler, we could use XMLConfiguration in ConfigurationFactory to parse
        > the definition file. Then we could use the whole Configuration API to access the
        > properties and could do wild things, too. Just a thought, but I enjoy such
        > recursive stuff!

        If you can use XMLConfiguration to read your config files, I would recommend that.

        However in reference to the original posting, I think setting Digester's
        useContextClassLoader is the correct thing to do, and should not have any
        side-effects. If this flag is defined but there is no context classloader set,
        then digester will effectively ignore the flag.

        The only possibility for problems is where contextClassLoader is set but you
        don't want to use that to load "user" classes. And I can't see why that would
        ever happen.

        Cheers,

        Simon (one of the maintainers of commons-digester)

        Show
        Simon Kitching added a comment - (In reply to comment #8) > Or even cooler, we could use XMLConfiguration in ConfigurationFactory to parse > the definition file. Then we could use the whole Configuration API to access the > properties and could do wild things, too. Just a thought, but I enjoy such > recursive stuff! If you can use XMLConfiguration to read your config files, I would recommend that. However in reference to the original posting, I think setting Digester's useContextClassLoader is the correct thing to do, and should not have any side-effects. If this flag is defined but there is no context classloader set, then digester will effectively ignore the flag. The only possibility for problems is where contextClassLoader is set but you don't want to use that to load "user" classes. And I can't see why that would ever happen. Cheers, Simon (one of the maintainers of commons-digester)
        Hide
        Oliver Heger added a comment -

        Simon,

        thank you for making things clearer.

        Then I am also +1 for applying this patch now. If we want to remove the
        dependency to digester, we can do this in the process of the refactoring of
        ConfigurationFactory.

        Emmanuel, are you going to apply this patch?

        Show
        Oliver Heger added a comment - Simon, thank you for making things clearer. Then I am also +1 for applying this patch now. If we want to remove the dependency to digester, we can do this in the process of the refactoring of ConfigurationFactory. Emmanuel, are you going to apply this patch?
        Hide
        Emmanuel Bourg added a comment -

        Go ahead and apply, I'm not fully operational with SVN yet

        Show
        Emmanuel Bourg added a comment - Go ahead and apply, I'm not fully operational with SVN yet
        Hide
        Mike Colbert added a comment -

        Thanks to everyone for weighing in and taking a look at the problem so quickly.

        Show
        Mike Colbert added a comment - Thanks to everyone for weighing in and taking a look at the problem so quickly.
        Hide
        Oliver Heger added a comment -

        Patch applied.
        Thank you very much!

        Show
        Oliver Heger added a comment - Patch applied. Thank you very much!
        Henri Yandell made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 33475 12342047
        Henri Yandell made changes -
        Project Commons [ 12310458 ] Commons Configuration [ 12310467 ]
        Component/s Configuration [ 12311107 ]
        Key COM-1895 CONFIGURATION-88
        Assignee Jakarta Commons Developers Mailing List [ commons-dev@jakarta.apache.org ]
        Affects Version/s unspecified [ 12311647 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Mike Colbert
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development