snip.....
>
>
>> 3) Cross-Bundle Class Loading Problems
>>
>> It turns out that some of the 3rd Party libraries that we use involve code
>> that loads classes from outside the library, but where there is no explicit
>> dependency of the 3rd party code on the code package(s) from which the
>> classes are loaded. Typically, this involves 3rd party code that supplies
>> library extension APIs where the NAME of an extensio class belonging to the
>> CALLER is passed in through the API, but the classes are instantiated by the
>> code within the API layer.
>>
>> There are 2 main cases of this:
>>
>> 1) Axis2 - the axis2-kernel-1.4.1 module. This has an API which is used
>> to load a class from our binding-ws-axis2 module.
>> 2) Axiom - the axiom-api module loads classes from the axiom-dom and from
>> the axiomn-impl modules
>>
>> In both these cases, there is no explicit dependency of the loading module
>> on the module from which the class(es) are loaded - and in reality, neither
>> should there be, since the other module is in a sense a "user" of the
>> loading module.
>>
>> I decided that the way to fix this was to patch the MANIFEST files of the
>> bundles concerned to use the Eclipse Buddy technology. This means that:
>>
>> a) The bundle doing the loading of these "foreign" classes is marked with
>> "Eclipse-BuddyPolicy: dependent"
>> - which says that the module has some "buddy" modules from which some
>> classes will be loaded
>>
>> b) The bundle(s) providing the loaded classes are marked with:
>> "Eclipse-RegisterBuddy: xxxxxxxxxxx"
>> - where xxxxxxxxxxxx is the symbolic name of the bundle from a) - and this
>> indicates that this
>> bundle provides classes to the first bundle.
>>
>> One problem with this approach is that it only works for Equinox and I
>> don't think it is available for other OSGi implementations such as Felix.
>>
>> We need to think harder about this problem, but something like the
>> BuddyPolicy solution is needed - and we need to coax the 3rd Party providers
>> to add this to their bundle manifests.
>>
>>
> It's a bit tricky if the 3rd part library is partially-baked OSGi bundle.
> If it is a plain jar, we export/import all the packages for the wrapping
> bundle and they can load all the publicly-exported packages. I see a few
> options to fix the 3rd party bundle issues:
>
> 1) Report the issue back to the owning project and get it fixed at the root
> 2) Treat them as non-OSGi bundle and use our folder-based bundle packaging
> technique to change the MANIFEST.MF
> 3) Add a fragment bundle to the 3rd-party bundle to patch the MANIFEST.MF
>
>
>>
>> Yours, Mike.
>>
>>
>>
>>
1) is the right answer but I suspect it will not move us forward very
quickly
As I understand it the axiom problem looks like a bug in the axiom
bundle so we should just raise a JIRA
The axis configuration is a bit more problematic. In this case axis is
trying to create an instance of a class that belongs to Tuscany. Axis should
support a different interface for providing configuration information, e.g.
pass in an object rather than a classname
2) This sounds like the easiest tactical fix but I;m not sure it works for
the Axis config problem as Axis needs access to a Tuscany class. How are the
imports defined in the wrapper bundle?
3) More complicated but this may have to be the tactical solution if 2)
isn't sufficient.
What we could do with is some configurable processing that allows us to
override the code that detects whether a jar is a bundle or not.
Simon
