SEC-1652: does not handle LDIF files contained in jars #1893

spring-issuemaster opened this Issue Jan 10, 2011 · 4 comments


None yet
1 participant

Brian Topping (Migrated from SEC-1652) said:

Because of the way that ApacheDSContainer creates, 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, 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.

Brian Topping said:

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

Luke Taylor said:

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.

Brian Topping said:

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.

Luke Taylor said:

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.

spring-issuemaster added this to the 3.1.0.RC1 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment