jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: [rmi] JCR-RMI 2.0.0 release plan
Date Mon, 06 Apr 2009 21:35:26 GMT

On Mon, Apr 6, 2009 at 7:50 PM, Felix Meschberger <fmeschbe@gmail.com> wrote:
> I think, we probably don't need to export everything from this bundle
> (yet, testing this would be important). Rather we should probably export
> the most important factory classes: The Server and the Client factories
> and keep the rest private as implementation details. The factories
> should take care of getting the class loaders straight.

Is there a benefit to doing that? Most of the RMI layer is designed to
be extensible and customizable through subclassing, so hiding the
classes would seriously cut the options available to users.

> In addition, the bundle contains Jackrabbit-API and hence a Jackrabbit
> dependency, which is what we wanted to prevent IIRC. The problem is not,
> that this module is _using_ jackrabbit API but it is _implementing_
> jackrabbit API, and this makes it even more problematic, since this
> generates versioning issues (the imports must be more strict).

I'm not sure I follow you. Any decorator layer will both use and
implement an API, and I don't think that JCR-RMI is somehow special in
this respect. If the (decorated part of the) API changes, then the
decorator layer needs to be updated too.

I'm not enough of an OSGi expert to know whether or how that should be
reflected in the bundle metadata.


Jukka Zitting

View raw message