jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lennard Fuller <lful...@unicon.net>
Subject Re: Remoting and future of JCR-RMI
Date Tue, 20 Oct 2009 23:53:11 GMT
I agree with Felix.  JCR-RMI definitely has it drawbacks (perf is HORRIBLE).  However, it is
easy to use and until the dav based communications is at least as easy, JCR-RMI should not
be dropped.


----- Original Message -----
From: "Felix Meschberger" <fmeschbe@gmail.com>
To: dev@jackrabbit.apache.org
Sent: Tuesday, October 20, 2009 10:58:19 AM GMT -07:00 U.S. Mountain Time (Arizona)
Subject: Re: Remoting and future of JCR-RMI

Hi,

At first sight, I would say nay ;-)

Because, the RMI stuff is easy and simple to use and just works. Period.

Now, on the other hand the RMI stuff has some serious drawbacks:
  * Performance (we never really built caching into it, which would
     be hard anyways)
  * Secondary communications channel besides HTTP
  * Classloading issues
  * .. and all the other problems related to RMI

Therefore, I agree with this proposal, all the more, that hopefully,
setting up a dav based communications channel supporting the complete
API (this would be a requirement for me for dropping RMI !) is as easy
and straightforward.

Regards
Felix

Jukka Zitting schrieb:
> 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
> 

Mime
View raw message