Brian Topping (Migrated from SEC-1652) said:
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.getFile().getAbsolutePath(). Instead, this would ideally be ldifs.getInputStream(), with ApacheDS lobbied to create a constructor for an InputStream instead of just String.
String ldifFile = ldifs.getFile().getAbsolutePath()
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.getFile(), maybe via ldifs.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.
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.
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.