Spring Security
  1. Spring Security
  2. SEC-1652

org.springframework.security.ldap.server.ApacheDSContainer#importLdifs does not handle LDIF files contained in jars

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 3.0.5
    • Fix Version/s: 3.1.0.RC1
    • Component/s: LDAP
    • Labels:
      None

      Description

      Because of the way that ApacheDSContainer creates org.apache.directory.server.protocol.shared.store.LdifFileLoader, there's no way to pass a classpath resource as the LDIF source.

      The problem is the call to String ldifFile = ldifs[0].getFile().getAbsolutePath(). Instead, this would ideally be ldifs[0].getInputStream(), with ApacheDS lobbied to create a constructor for an InputStream instead of just String.

      Failing that, org.apache.directory.server.protocol.shared.store.LdifFileLoader#getLdifStream already deals with classpath resources, but ApacheDSContainer needs to not fail so fast via ldifs[0].getFile(), maybe via ldifs[0].getPath().

      I'd submit a patch, but I can't build with gradle. It was too much of a PITA to get set up and I swore it off, sorry.

        Activity

        Hide
        Brian Topping added a comment -

        p.s. Apparently the wikitext renderer in Jira is not activated. Someone might want to check on that!

        Show
        Brian Topping added a comment - p.s. Apparently the wikitext renderer in Jira is not activated. Someone might want to check on that!
        Hide
        Luke Taylor added a comment -

        I've changed the code to resolve the resource to a URI rather than a file, which should allow for loading from jar files as well as the file system.

        Regarding gradle, you shouldn't need to "get set up" (though installing gradle should only require a download plus editing the path). Use the wrapper script as described in the "Build from Source" page on the website.

        Show
        Luke Taylor added a comment - I've changed the code to resolve the resource to a URI rather than a file, which should allow for loading from jar files as well as the file system. Regarding gradle, you shouldn't need to "get set up" (though installing gradle should only require a download plus editing the path). Use the wrapper script as described in the "Build from Source" page on the website.
        Hide
        Brian Topping added a comment -

        Thanks for the fix, Luke.

        Regarding Gradle, there's a saying that "one only has one chance to lose a customer" and I'm kind of lost already. I never understood why Gradle was considered necessary in the first place. Like others, I have a large investment in Maven, and while Gradle may be better, it's only an incremental jump over Maven (versus the jump Maven was from Ant). I'll stick with Maven until there's a more compelling reason to jump. It kind of sucks to not be able to create patches for projects like SS, but they are very few and far between.

        Show
        Brian Topping added a comment - Thanks for the fix, Luke. Regarding Gradle, there's a saying that "one only has one chance to lose a customer" and I'm kind of lost already. I never understood why Gradle was considered necessary in the first place. Like others, I have a large investment in Maven, and while Gradle may be better, it's only an incremental jump over Maven (versus the jump Maven was from Ant). I'll stick with Maven until there's a more compelling reason to jump. It kind of sucks to not be able to create patches for projects like SS, but they are very few and far between.
        Hide
        Luke Taylor added a comment -

        This isn't really the place to discuss mvn versus gradle - suffice to say that it makes my life much easier and I would regard it as much more than an incremental jump.

        My point is that you don't need to use it yourself and there's no reason why you shouldn't be able to build Spring Security because we are using it. All you have to do is type "./gradlew build" from the project root directory to build the entire project. So I don't get the business about losing customers - you didn't have to understand maven to use the previous build and now you don't even have to install the build tool in order to use it. So there's no reason why it should stop anyone from submitting patches.

        Show
        Luke Taylor added a comment - This isn't really the place to discuss mvn versus gradle - suffice to say that it makes my life much easier and I would regard it as much more than an incremental jump. My point is that you don't need to use it yourself and there's no reason why you shouldn't be able to build Spring Security because we are using it. All you have to do is type "./gradlew build" from the project root directory to build the entire project. So I don't get the business about losing customers - you didn't have to understand maven to use the previous build and now you don't even have to install the build tool in order to use it. So there's no reason why it should stop anyone from submitting patches.

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Brian Topping
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: