well, jackrabbit.jar may not have been the culprit, but something was. i moved all of my webapps' shared resources and classes into $CATALINA_HOME/common/lib and $CATALINA_HOME/common/classes, and now the custom access manager works.
might have been an overkill solution, but i didn't have the time to drop in each jar individually and figure out which might have been the problem. if somebody else has this issue and finds out, i'd love to know.
Brian Moseley wrote:
thanks!
hm.. i copied the jackrabbit jar into $CATALINA_HOME/common/lib, but i'm still getting the same problem.
Philipp Koch wrote:
i ran into a similar problem.
my setup was:
- webapp 1 running a jackrabbit repository(A)
- webapp 2 running a jackrabbit repository(B) which i registered using jndi
(both repository use the SimpleAccessManager)
when i tried to access the repository B in webapp 1 via jndi i ran
into similar problems with the authentication stuff as you described
above.
this solution worked for me:
i moved following class files from the "jackrabbit.jar" into a newly
created jar-file (e.g. jackrabbit-security.jar):
- org\apache\jackrabbit\core\security\AnonymousPrincipal.class
- org\apache\jackrabbit\core\security\CredentialsCallback.class
- org\apache\jackrabbit\core\security\CredentialsCallbackHandler.class
- org\apache\jackrabbit\core\security\SimpleLoginModule.class
- org\apache\jackrabbit\core\security\SystemPrincipal.class - org\apache\jackrabbit\core\security\UserPrincipal.class
i put this jar-file in the $JETTY_HOME/ext folder (for jetty). (in
your case $CATALINA_HOME/common/lib).
it than worked fine. i could not find a more elegant way to solve this problem so far. i am not sure if the use case helps to solve your problem...
