Hi, I managed to bring up the binding-ws-calculator sample with the following changes:
1) Make binding-ws-axis2 a fragment to axis2-kernel to work around the MessageReceiver classloading issue from axis2 2) Make databinding-axiom a fragment to axiom-api to work around the SOAP11Factory classloading issue from axiom 3) Change the osgi.contextClassLoaderParent to "app" to work around the DataTypeFactory classloading issue inside Eclipse 4) Change the sample to fork a client thread to do the calculation instead of the "init" method. The init() can be called when the web service is not ready and it will cause deadlock. It's not ideal but it seems to be a good step. Thanks, Raymond From: Simon Laws Sent: Tuesday, January 27, 2009 9:08 AM To: [email protected] Subject: Re: [2.0] Getting Web Services binding running - some entertainment 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
