On Wed, Jan 28, 2009 at 12:59 AM, Raymond Feng <[email protected]> wrote:
> 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 <[email protected]> > *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 > Good work Raymond. I just ran binding-ws-calculator in Eclipse and it works for me with the latest code. I think 1, 2 and 3 are reasonable tactical changes. 4 is a bit more problematic. Two points. - one does the spec say/imply that we should be able to use references from @init methods regardless of binding type. It's interesting that this works for binding.sca - we should do something else rather than forking here. Just rely on service exposed through SCA and use non-sca clients? I'll make some changes and get feedback. Simon
