Has the JCA Ever Worked? It can't according to its documentation

Question

I am working on a JCA implementation of Jackrabbit with a custom JAAS login module. The idea is to integrate Apache Shiro authentication and authorization via the login module, using a RepositoryLoginContext that simply furnishes user name and password from a Shiro token for the callback functions. (I have only a small number of users, which are configured with a shiro.ini file.)

All the pieces seem to fit until I try connecting to the repository. One attempt is

SimpleCredentials userJCACredentials = new SimpleCredentials(username,shriroUserCreds.getPassword().toString());

but I cannot seem to find a build path JAR that makes it happy. The Jackrabbit API docs have me flummoxed. If I look for SimpleCredentials, I get a Day Software page (!) however if I look for CryptedSimpleCredentials, I get an Apache page. Thinking that perhaps only the crypted version can be used with the resource adapter, I tried changing to that but run into the same problem with

connInfo = new JCAConnectionRequestInfo(cryptedCreds,workspaceName)

which only wants SimpleCredentials in the first argument. I keep finding dead ends in the API, such as JCAConnectionRequestInfo(Credentials creds, String workspace). If you click on the Credentials link, it times out. Another gem is one of JCAManagedConnectionFactory's constructors, which has text about IBM Websphere (!!).

I tried writing my own class (based onsimple credentials) implementing Credentials interface and the error with

new JCAConnectionRequestInfo(cryptedCreds,workspaceName)

turned into inability to resolve javax.jcr.Credentials. With a Jackrabbit installation, the javax.jcr path does not exist (at least for the resource adapter version).

Failing to make any sense of the foregoing, I tried a second approach.

repoParameters.put("homeDir",ARCHIVE_REPO_DIR);
repoParameters.put("configFile",ARCHIVE_REPO_CONFIG);
repoMan = JCARepositoryManager.getInstance();
repo = repoMan.createRepository(repoParameters);

The last line, using a Map argument, was prompted by Eclipse auto completion, in conflict with the documentation showing createRepository( string, string ). In any case, an error about resolution of javax.jcr.Repository appears. Back to the same stuff.

I've explored every bottom up path in the libraries to get a Session. It seems to be impossible, ultimately failing for a non-existent definition.

Looking the source code, I've assembled the following

 JCAManagedConnectionFactory mcf = new JCAManagedConnectionFactory();
    mcf.setConfigFile(...);
    mcf.setHomeDir...);
    try {
        mcf.setLogWriter(lpw);
        connectionFactory = mcf.createConnectionFactory();
    } catch (ResourceException rex) {
        logger.error("client session failed to create connection factory");
        logger.error(rex);
    } finally {
        success = false;
    }
    if (success) {

        repo = (RepositoryImpl) connectionFactory;
        session = repo.login( needs Credentials Here );
    }

The login call needs Credentials and a workspace name. If the login is going to be handled by JAAS, I'd expect to find a login() with no arguments wherein the JAAS login would take over.

Answer 1

I used jackrabbit a couple of years ago in a project and had some small success with it but then moved from jackrabbit to modeshape which is an alternative implementation of the JCR (JSR-283. This is a very active project in which I have had a (very small) involvement. Development continues at a great rate with new releases regularly coming out.

I started with version 2.8 which wasn't bad but the 3.0 release was an almost complete rewrite with a focus on performance and was a delight to use. 4.0 is now in the last stages of being released.

The changeover from Jackrabbit (2.2.7) to Modeshape (2.8.1) was relatively painless with most of the effort in setting up the configuration and runtime.

I'm not saying you won't find problems like you are seeing in Jackrabbit but if you ask a question in the modeshape forums you will get a good answer and plenty of ongoing help.

Answer 2

Lessons Learned:

Integrating Shiro was not a great idea, but not at all because of Shiro. The JCA requires JAAS login. "Integrating" Shiro requires enough understanding of JAAS that I might as well just adopt JAAS and be done with it. But getting further along, I realized that it was fine. There are larger issues ahead.

JAAS is, well, JAAS. I was far from able to breeze through it and pick up what I needed although I have gotten pretty far. The answer to the last dilemma in the post is simply that the login method called is not found in the JCA, it's found in the JAAS login module that you code and "register" through the Geronimo admin console by creating a new security real for you application. A large part of the JAAS learning curve is that it the model is very abstract. There is no "JAAS in a nutshell for Geronimo" to enlighten would-be programmers. Another part is that it is so widely used, information specific to everything but what I'm doing seems ubiquitous. It isn't surprising because web apps are by far it's greatest usage. And following that, it is not really surprising to find a JAAS login module with Jackrabbit as the JCR was envisioned for web content.

It turns out that burrowing into JAAS, though enlightening, was a complete waste of time. After putting the effort into getting JAAS together, I finally had a Jackrabbit Session Handle. I immediately put it to work on a utx wrapped piece of old code.

Things stopped cold here. None of my old code worked, starting with getRootNode(). I let Eclipse show me the possible methods for a session handle and I tested each one. The list of those that work is short. Some UTX related stuff works, as does "equals", hasCapabilty, isLIve, and little else. Sixty plus methods of the Session Handle cannot work. THIS MEANS THAT THERE IS NO WAY TO GET A NODE. WHICH MEANS YOU CANNOT DO ANYTHING USEFUL WITH THE JCA.

As to my original question, I will say that at one point the JCA probably did work. After all, no one would code all that stuff just to have it lined out. And I will also say that whenever the code was modified to use JAAS, it was badly broken and rendered useless.

This really is a soapbox moment. The amount of time I invested in this was significant. One reason I wanted to use Jackrabbit was that it could run in the same JVM as my application, in Geronimo. I can understand documentation that isn't up to par and other realities of open source. But I could only speculate about how this happened, and the alternatives are all pretty negative. I smelled a rat earlier but said nothing.

One thing is clear. The JCA (and for all I know, the rest of the Jackrabbit project) has no business being touted as an Apache Project. It is a disservice to their name and an extreme disservice to developers who've been led down a dead end path.

I am not sure how to go about it, but I want to bring this to the attention of the Apache foundation if for no other reason than preventing anyone else from going through this.