Thanks for your swift answer.
Stefan Guggisberg wrote:
Yeah, I do agree with that. Especially if others third part components use these properties.hi bertrand,
thanks for the patch. unfortunately it doesn't solve the issue and
it is imo dangerous. setting predefined system properties
from within an application can cause unpredictable side effects and should be avoided.
But I find strange to configure the JAAS authentication at JVM level.
Anyway, you're right.
please see the thread "Pluggable authentication" for a suggested solution.Oops. I guess I missed that thread.
I have the same concerns as Sylvain. Be able to use JAAS but doesn't want to modify the JVM settings.
I'm eager to test the release you talked about :)
btw:Thanks for the details. I'm not proficient with JAAS. So if I did understantd well, there is no dependency to the installed configuration. The configuration class I mentionned is just the default one dynamically loaded.
* As the current implementation uses the <code>com.sun.security.auth.login.ConfigFile</code>
* as the current provider for the login configuration, the application
this is not correct. jackrabbit has no dependencies on com.sun.security.auth.login.ConfigFile. all it does is
lc = new LoginContext("name", callbackHandler);
i.e. it uses the installed Configuration, what ever that might be.
This is the point. I tried to use the following code to connect to the repository :* All that is very boring and breaks compatibility.
(1)
RepositoryConfig config = RepositoryConfig.create( configFilePath, repositoryPath ) ;
RepositoryImpl repository = RepositoryImpl.create(config) ;
Session session = null ;
session = repository.login( );
I didn't manage to get it worked. I'm not very used to jackrabbit for the moment, so I'm sure that I must have done something wrong.
The truth is that the following code does work :
(2)
RepositoryConfig config = RepositoryConfig.create( configFilePath, repositoryPath ) ;
RepositoryImpl repository = RepositoryImpl.create(config) ;
Session session = null ;
System.setProperty("java.security.auth.login.config", "c:\\temp\\jaas.config" ) ;
session = repository.login( );
So I was under the impression that the support of JAAS was breaking the compatibility with older code.
Could you confirm that the code in (1) still works fine ?
This was more a hack to address that issue (if you confirm it is one).
sorry, i don't agree. i don't see why this would be 'boring'.
and what 'compatibilty' does it break?
Well the "boring" comment is very personal. Never mind.
The fact is that the new implementation requires the developper to have a knowledge of what is JAAS (and how to configure it) even if his application won't use it.
This is what I meant by boring.
The "pluggable authentication" is IMHO more appropriate. And furthermore, on its way to the release :)
Regards, Bertrand.
