Log4j 2
  1. Log4j 2
  2. LOG4J2-445

ResolverUtil cannot find packages in file URLs which include the '+' character

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta9
    • Fix Version/s: 2.0-rc1, 2.0
    • Component/s: Core
    • Labels:
      None
    • Environment:

      Debian Squeeze and Gentoo
      Java 7u25

      Description

      I work on an application whose version number includes a '+' character which becomes part of the filename for the jars created in the build process. This application uses several custom log4j2 plugins contained in the jar which are discovered via the packages tag in the xml Configuration. We also generate a plugin map using the exec-maven-plugin command documented in the Extending log4j section of the log4j2 documentation. This command prints the following during the build:
      ERROR StatusLogger Could not search jar file '/src/program-1.2.3 build127/util/target/util-1.2.3 build127.jar' for classes matching criteria: annotated with @Plugin file not found
      The actual path to the jar is '/src/program-1.2.3+build127/util/target/util-1.2.3+build127.jar'

      I examined the source for ResolverUtil and in the method findInPackage (line 225), URLDecoder.decode is called unilaterally even for file: URLs. The javadoc for this class says the character + is converted to space, which is inappropriate for a file: URL.

      1. resolver-util-file-with-plus.patch
        1 kB
        Anthony Baldocchi
      2. resolver-util-jar-file-path-with-plus.patch
        1 kB
        Anthony Baldocchi

        Activity

        Hide
        Remko Popma added a comment -

        I've taken a slightly different approach than the patch:

        Instead of calling URL.toExternalForm (which theoretically could include the Host, Query and Ref parts), I only do string processing on the Path part.

        Stripping of "jar:" and "file:" prefixes and "!/*" suffix is as before.

        Finally, deciding whether to URL.decode or not:

        • vfszip: and bundleresource: URLs are never decoded,
        • if the path exists as a file (without decoding it), then return it as is
        • otherwise, return the URL.decoded path

        Added JUnit tests.
        Fixed in revision 1555458.
        Please verify and close.

        Show
        Remko Popma added a comment - I've taken a slightly different approach than the patch: Instead of calling URL.toExternalForm (which theoretically could include the Host, Query and Ref parts), I only do string processing on the Path part. Stripping of "jar:" and "file:" prefixes and "!/*" suffix is as before. Finally, deciding whether to URL.decode or not: vfszip: and bundleresource: URLs are never decoded, if the path exists as a file (without decoding it), then return it as is otherwise, return the URL.decoded path Added JUnit tests. Fixed in revision 1555458. Please verify and close.
        Hide
        Remko Popma added a comment -

        Hmm... to answer my own question,
        it looks like the only URL protocols that are actually supported by the current ResolverUtil.findInPackage() implementation are file:, jar:file:, vfszip: and resourcebundle:. Any other protocol URL will be be handled as a local File.
        I'll create JUnit tests accordingly.

        Show
        Remko Popma added a comment - Hmm... to answer my own question, it looks like the only URL protocols that are actually supported by the current ResolverUtil.findInPackage() implementation are file: , jar:file: , vfszip: and resourcebundle: . Any other protocol URL will be be handled as a local File . I'll create JUnit tests accordingly.
        Hide
        Remko Popma added a comment -

        I'm working on the JUnit tests.
        Would it be sufficient to have tests for the file:, the jar:file: and the http: protocols or can anyone think of other URL protocols that ClassLoader.getResources() might return?

        Show
        Remko Popma added a comment - I'm working on the JUnit tests. Would it be sufficient to have tests for the file: , the jar:file: and the http: protocols or can anyone think of other URL protocols that ClassLoader.getResources() might return?
        Hide
        Ralph Goers added a comment -

        Remko - I see you assigned this to yourself. I don't see anything wrong with this patch but we should have a unit test for ResolverUtil to prove that it works.

        Show
        Ralph Goers added a comment - Remko - I see you assigned this to yourself. I don't see anything wrong with this patch but we should have a unit test for ResolverUtil to prove that it works.
        Hide
        Anthony Baldocchi added a comment -

        The previous patch was insufficient for jar:file: URLs.

        Show
        Anthony Baldocchi added a comment - The previous patch was insufficient for jar:file: URLs.
        Hide
        Anthony Baldocchi added a comment -

        proposed fix for ResolverUtil.findInPackage

        Show
        Anthony Baldocchi added a comment - proposed fix for ResolverUtil.findInPackage

          People

          • Assignee:
            Remko Popma
            Reporter:
            Anthony Baldocchi
          • Votes:
            4 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1h
              1h
              Remaining:
              Remaining Estimate - 1h
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development