Commons Configuration
  1. Commons Configuration
  2. CONFIGURATION-47

[configuration] ConfigurationFactory loading from classpath issue

    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: All
      Platform: All

      Description

      I found a thread on the commons mailing list about this topic, but did not see a
      resolution presented.

      http://www.mail-archive.com/commons-user@jakarta.apache.org/msg07782.html

      It seems the only way to load a properties file from a separate jar in the
      classpath is to use absolute paths. I believe the ConfigurationFactory
      framework would be a tad more useful if it used the classloader to load the
      properties files as resources instead. The major advantage being that one could
      package a default properties file in a config jar, but temporarily override it
      by placing a copy higher in the classpath. There are other uses as well, but
      that's the main use case I have in mind right now.

      Let's say I have the following JAR that contains only these configuration files:

      core-config
      properties/config.xml <= The ConfigurationFactory settings
      properties/test-config.xml <= An XML properties file

      core-configtest
      com.test.ConfigurationTest <= Constructs ConfigurationFactory and calls
      getConfiguration()

      Because I use the classload to load

      <!-- config.xml -->
      <configuration>
      <xml fileName="test-config.xml"/>
      </configuration>

      I have tried many variations of the above path to get it to load from the
      classpath to no avail, such as:

      <xml fileName="properties/test-config.xml"/>
      <xml fileName="/properties/test-config.xml"/>
      <xml fileName="file:test-config.xml"/>
      <xml fileName="file:properties/test-config.xml"/>
      <xml fileName="file:/properties/test-config.xml"/>

      Most of the time it coughs out a SAXException with a garbled path like this:

      Could not load from
      C:\dev\Java\Core-ConfigTest\file:\C:\dev\Java\Core-ConfigTest\lib\core-config.jar!\properties\test-config.xml
      at org.apache.commons.digester.Digester.createSAXException(Digester.java:2540)
      at org.apache.commons.digester.Digester.createSAXException(Digester.java:2566)
      at org.apache.commons.digester.Digester.endElement(Digester.java:1061)

      In other words, I can't seem to make it use the appropriate URL for accessing
      the file when it's in another JAR.

      jar:file:/C:/dev/Java/Core-ConfigTest/lib/core-config.jar!/properties/config.xml

      If I move the properties folder to the JAR that contains the test class, it
      works fine. I believe I could also use an absolute path to the properties file,
      but again, that precludes me from being able to quickly override the properties
      file by placing a copy higher in the classpath.

      This is my first experience with trying to initiate a change in an open source
      project, so bear with me if I'm not following the right protocol. I'd like to
      take a stab at creating a patch myself if someone hasn't already beat me to it.

      Thanks.

        Activity

        Hide
        Emmanuel Bourg added a comment -

        Fixed, all file based configurations can now be loaded from the classpath, tell
        us if it works for you Joe.

        Show
        Emmanuel Bourg added a comment - Fixed, all file based configurations can now be loaded from the classpath, tell us if it works for you Joe.
        Hide
        Emmanuel Bourg added a comment -

        Taking the bug, a fix is on the way !

        Show
        Emmanuel Bourg added a comment - Taking the bug, a fix is on the way !
        Hide
        David Eric Pugh added a comment -

        Your bug report looks nicely detailed! The key thing to keep in mind when
        submitting a fix is to include a unit test! This makes it easier for the
        maintainers to have something to verify your fix against, and ensures the bug
        doesn't come back. If you need any help, holler.

        Show
        David Eric Pugh added a comment - Your bug report looks nicely detailed! The key thing to keep in mind when submitting a fix is to include a unit test! This makes it easier for the maintainers to have something to verify your fix against, and ensures the bug doesn't come back. If you need any help, holler.

          People

          • Assignee:
            Unassigned
            Reporter:
            Joe Holloway
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development