Hi, So far I've just assumed that, since JCR 2.0 is backwards compatible with JCR 1.0, we'll have no trouble using the JCR-RMI layer on top of a JCR 2.0 repository even if the layer itself is still built against JCR 1.0.
Unfortunately, now that I looked at this in more detail, my assumption turns out to be false. Since the JCR-RMI layer acts both as a JCR client and a server it's not possible for one end to use JCR 1.0 while the other uses JCR 2.0. Furthermore the remote interfaces and objects passed through RMI include javax.jcr.RepositoryException and a serializable javax.jcr.Value implementation, so even just splitting the JCR-RMI layer to separate client and server parts will not solve the problem. With enough work we could solve both of the above issues to make JCR-RMI work with all combinations of JCR 1.0 and 2.0 clients and servers. However I'm not convinced that it makes sense to spend all that effort when we now have the WebDAV-based remoting layer that's already pretty feature-rich. So I'm thinking of putting JCR-RMI on a maintenance track for old 1.x releases, and perhaps even dropping the RMI layer entirely from Jackrabbit 2.0. WDYT? BR, Jukka Zitting
