Hi, On Tue, Jun 7, 2011 at 2:45 PM, Edouard Hue <[email protected]> wrote: > Sadly, I won't have time to develop this for the momen, but I found another > way : I deploy the JCA adapter and expose it through the remoting servlets > in jackrabbit-webapp.
Yes, it's should be fairly straightforward to use the webapp to look up the JCA repository from JNDI and then bind it to the RMI registry for use by remote clients. Accessed that way, even transactions should work properly. > 1. org.apache.jackrabbit.servlet.remote.RemoteBindingServlet expects the > repository to be exposed via a servlet context attribute only and doesn't > make use of org.apache.jackrabbit.j2ee.RepositoryAccessServlet ; The jackrabbit-jcr-servlet component contains both Repository- and BindingServlets. The repository servlets set the servlet context attribute after acquiring a repository instance either by looking it up somewhere or by creating it locally. The binding servlets take that repository reference from the servlet context attribute and bind it to some external location like a JNDI directory or the RMI registry for use by external clients. RepositoryAccessServlet is an older mechanism designed mostly just for the jackrabbit-webapp. To configure Jackrabbit webapp for this, you'd configure a JNDIRepositoryServlet [1] to look up the JCA repository from the local JNDI directory and an RMIRemoteBindingServlet [2] instance (or any other RemoteBindingServlet subclass) make the looked up repository available to remote clients. To still keep the rest of jackrabbit-webapp operational, you'd remove the RepositoryStartupServlet configuration and enable the repository.context.attribute.name parameter of the RepositoryAccessServlet. [1] http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/servlet/JNDIRepositoryServlet.html [2] http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/servlet/remote/RMIRemoteBindingServlet.html > 2. The JCA adapter brings its own slf4j implementation (logback), shouldn't > this be a user choice ? The RAR archive is expected to be a fully self-contained unit of functionality, so we need to include also a logging library inside it. A user who wants a different logging mechanism can always repackage the RAR. BR, Jukka Zitting
