Hi, One environment that springs to mind is WebSphere Application Server (version 7 and 8), another is the application itests. Those both use composites for isolation and version 4.2 frameworks. Moving the application itests up to R43 should be possible, but getting changes in WebSphere might be an issue! I'm not sure if any other platforms would be affected, do Karaf and Geronimo both use R43?
Tim Ward ------------------- Apache Aries PMC member & Enterprise OSGi advocate Enterprise OSGi in Action (http://www.manning.com/cummins) ------------------- > Subject: Re: Utils changes > From: [email protected] > Date: Sat, 12 Nov 2011 00:11:01 -0800 > To: [email protected] > > 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 idea. > > 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. > > thanks > david jencks > > > On Nov 10, 2011, at 8:53 AM, Jeremy Hughes wrote: > > > On 10 November 2011 15:24, John W Ross <[email protected]> wrote: > >>> > >>> Re: Utils changes > >>> > >>> On 10 November 2011 04:21, David Jencks <[email protected]> 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 > >>> osgi.org/bugzilla 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 > >>>> > >>>> > >>> > >> >
