jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: Jackrabbit SPI export version
Date Wed, 25 Jan 2012 07:53:08 GMT
Hi,

Am 25.01.2012 um 01:37 schrieb Jukka Zitting:

> Hi,
> 
> On Wed, Jan 25, 2012 at 1:06 AM, Tobias Bocanegra <tripod@adobe.com> wrote:
>> how about adding getSelectorJcrNames() and deprecate the other one?
> 
> Yes, we can do that. It just feels silly that we have to go through
> hoops like that when AFAICT were the only ones using and implementing
> this interface.

True, but think about downstream deployers and secondary users like Sling.

But, hmm, hmm, hmm, I may have made a mistake .. updating the SPI, SPI Commons, WebDav, and
JCR Commons bundles to 2.3.7 while still having had an old DavEx build embedding JCR Server
2.3.4 (or another pre-2.3.7 version).

This bombed because the DavEx bundle imported spi at [2.4,3) thus precluding to operate with
SPI 2.3.7 exporting spi at 3.

> 
> And (correct me if I'm wrong), isn't the OSGi framework supposed to be
> able to deal with cases where for backwards compatibility reasons more
> than one version of a package needs to be present?

You don't want to enter the arena of deploying the same bundle in different versions. The
framework perfectly knows how to deal with this. Our software probably not ... Point is building
a consistent class space where different actors use the same classes.

> 
> I'd understand this desire better if the objection was about 1233468
> (the actual API change) rather than 1227240 (the OSGi package version
> update). Is there any actual client or implementation code that gets
> broken by revision 1233468 but that I didn't already update? Why then
> is revision 1227240 causing trouble?

The export version changed caused the problem to be flagged. Given the API change, the version
change was the right thing to do such that the issue could be flagged. I tried to make this
clear in my follow-up.

Maybe the real problem is with the setup of the JCR Server library: we made this a bundle
without any exports but with a Declarative Services descriptor for the added DavexServletService.

This requires me in Sling to embed the JCR Server library to implement something slightly
different on-top of the JcrRemotingServlet.

Maybe we should export packages from the JCR Server library and modify the DavexServletService
setup such that it is inoperable unless configuration is provided (or support configuration
to disable it). This would help me in Sling to my stuff based on JcrRemotingServlet and be
less bound to Jackrabbit internal dependencies.

Nevertheless, I think that breaking backwards compatibility in exported packages should not
have been done.

Regards
Felix

> 
> BR,
> 
> Jukka Zitting


Mime
View raw message