aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Utils changes
Date Sat, 12 Nov 2011 08:11:01 GMT
I can't think of a way to blame the problems on the spec :-)

I got everything I could find working and committed in rev 1201220.  I split utils into two
parts, a R42 bit with most of the old code, compiled against the 4.2 core, and a few new classes
and their dependencies that need R43.  This latter module pulls in the R42 code using the
bundle plugin.  I tried a couple other things such as having both the R42 and R43 cores in
the classpath, R42 first, but this doesn't work.

At the moment I have the RecursiveBundleTracker set up to use my new filter hook based approach
for any R43 environment.  After I realized I needed to deal with the initial bundles as well
as events, all the tests including those for composite bundle based isolation started passing.
 While I'm not very confident that this proves it will work for all R43 composite bundle scenarios,
it's a good sign.  Review and testing in actual composite bundle environments would be a good

Are there any R42 composite bundle environments?  If not and if my new code actually works
for composite bundles we might not need the old composite bundle recursive tracker.

david jencks

On Nov 10, 2011, at 8:53 AM, Jeremy Hughes wrote:

> On 10 November 2011 15:24, John W Ross <> wrote:
>>> Re: Utils changes
>>> On 10 November 2011 04:21, David Jencks <> wrote:
>>>> Apparently I did something wrong when testing these changes and
>>> there seem to be a couple of test problems caused here.
>>>> 1. A couple of blueprint tests fail with the new tracker.  I think
>>> they are testing blueprint using composite bundles.  Since composite
>>> bundles are a non-standard feature I wonder if it would be plausible
>>> to have a switch to turn on composite bundles support in recursive
>>> bundle tracker?
>>>> 2. Apparently code compiled against R4.3 can't be used with R4.2?
>>>  Compiling aries utils with R4.3 (so the code I added can compile,
>>> since it uses R4.3 classes) results in code that calls
>>> Version.compareTo(Version) which results in a NoSuchMethod error
>>> when called in a R4.2 framework where the method is
>> Version.compareTo(Object).
>>> This looks like a binary incompatible change was made in the R4.3 spec
>>> without incrementing the major version of the package (it went from
>>> 1.5 to 1.6). The R4.2 Version class implements java.lang.Comparable.
>>> The R4.3 Version class implements java.lang.Comparable<Version> so the
>>> signature has changed. That's worth opening a bugzilla on
>>> IMHO.
>> If I understand correctly, code was compiled against R4.3 (1.6) and those
>> binaries were then executed on R4.2 (1.5). I think we've reversed the
>> logic on the binary compatible requirement. Code compiled against R4.2
>> (1.5) will run on R4.3 (1.6), which is why a major version increment was
>> not necessary. I'm not aware of any expectations that code compiled
>> against a later version must run on an older version.
> You make a good point. I too was getting them the wrong way round. I
> retract what I said ealier!
>>>> Does anyone have any ideas how to work around these problems?  If
>>> anyone wants to revert my commits while we figure out what to do, go
>> ahead.
>>>> thanks
>>>> david jencks
>>>> On Nov 9, 2011, at 6:05 PM, David Jencks wrote:
>>>>> I made a couple changes to utils (issues 777 and 778) to provide
>>> R43 bundle-to-classloader determination and to make the
>>> RecursiveBundleTracker work with equinox Region based isolation as
>>> well as the obsolete composite bundle support.  Aries seems to build
>>> fine for me and I can get the blueprint extender to work in an
>>> isolated region using this, but I didn't try very hard to see if it
>>> broke stuff in earlier frameworks.  Please let me know if there are
>> problems.
>>>>> The approach I used for the bundle tracker is to register a
>>> bundle event hook and feed the events to a bundle tracker (code
>>> copied from felix's bundle tracker).  This avoids all bundle event
>>> filtering.  If anyone thinks this approach is inappropriate please
>>> speak up :-)
>>>>> thanks
>>>>> david jencks

View raw message