Hi Jackrabbit developers, I have been quite passive on this list for a long time, but I have finally been able to work with Jackrabbit a bit more, and I really need your help at this point :)
I have been trying to deploy Jackrabbit on one of the most unforgiving platforms : Websphere 6.1 and Oracle 9/10/11g. I have struggled quite a lot, and I had to revert to webapp-based deployment because the JCA deployment model just didn't fit well with the software I'm trying to integrate with (I was having issues with the authentification&authorization that was not possible to integrate into the connector). I managed to make most of it work, but I am now facing an issue that looks like an architectural issue, which is why I am writing here. Basically the problem I am seeing is that Websphere is complaining about accessing JNDI resources outside of container-managed threads. In the specific case I am investigating, this happens in the ObservationDispatcher class, that creates a thread for handling the notifications. Websphere refuses to serve the managed datasource because the threads are not managed by him. >From my point of view I have the following options : - directly connect Jackrabbit to the database, without using the container datasource and using JDBC connections - modifying the thread creation in Jackrabbit to maybe use something like the CommonJ Workmanager interface that allows the creation of contained managed threads The first solution I keep as a last solution, because I think that clients using Websphere will not like the idea of having JDBC connections that they have no control over. So I'd prefer to work on the thread creation part, but here I have the problem that the ObservationDispatcher class, from what I could understand of the source code, is not pluggeable so I couldn't replace it without really patching the code. Does this analysis look right ? Did I miss something ? I should point out that I am more than willing to do whatever work could help this issue out, as I am under a rather aggressive timeline to make all of this work. Best regards, Serge Huber.
