Bugzilla – Full Text Bug Listing
| Summary: | WeavingHook causes failure due to missing packages | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Brian <pradine> | ||||
| Component: | Framework | Assignee: | Thomas Watson <tjwatson> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | timothyjward, tjwatson | ||||
| Version: | unspecified | ||||||
| Target Milestone: | Juno M5 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Server 2003 | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 368248 | ||||||
| Attachments: |
|
||||||
|
Description
Brian
Moving to Framework: I assume aries is using the standard WeavingHook provided by the R4.3 OSGi framework. I would assume the weaving hook implementation would add the dynamic imports for these two packages if it wove bytecode into the class that required this. Do you know if it is doing that? Is there anything else you can tell us about the scenario? Let me take a guess that composites are somehow involved. If so does the composite which contains the affected bundle import the packages? Hi Tom, Your assumption about the use of composite bundles is correct. The relevant packages are being propagated into the composite. The weaving hook implementation in question can be found here: https://svn.apache.org/repos/asf/aries/trunk/proxy/proxy-impl/src/main/java/org/apache/aries/proxy/impl/weaving/ProxyWeavingHook.java As you can see it is attempting to add dynamic imports, but I do not believe that it is working. In your testing could you confirm that you can load the class org.apache.aries.proxy.weaving.WovenProxy from the composite surrogate bundle? For example:
CompositeBundle composite = ... get your problem composite
SurrogateBundle surrogate = compositeBundle.getSurrogateBundle();
try {
surrogate.loadClass(
"org.apache.aries.proxy.weaving.WovenProxy");
} catch (ClassNotFoundException e) {
... error case, the surrogate should be able to load this class
}
I have released a testcase for the scenario as I understand it and it passes:
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=aefd5bd422b0f347c291f061805e0468f975d8ff
My theory is that if you don't have a bundle in your composite that explicitly imports a package then the aries application container will not setup the composite to actually import the packages you need when you weave a class. This is my reason for asking if you can load the class in question from the surrogate bundle for the problematic composite. I think you are running into this issue because of a class space consistency issue (introduced by the uses: directive) when trying to dynamically resolve the proxy package for the woven bundle. If you have a composite definition which imports a package which is provided by the system.bundle from the parent framework then we end up with a surrogate bundle inside the composite framework which has a substitutable export (it exports and imports the package. In your particular case I think the proxy packages you import must have a uses: constraint on the org.osgi.framework package. Ultimately this ends up causing the surrogate bundle to both import and export the org.osgi.framework package. The surrogate's import is scoped to only allow it to get wired to the system.bundle with a matching attribute bundle-symbolic-name=system.bundle. What I suspect is happening in your case is that the surrogate bundle is not being allowed to import this package and ultimately does not have its export of org.osgi.framework be substituted with the real package from the system bundle. The most likely cause of this is some resolver hook which is hiding the org.osgi.framework package from the surrogate bundle. I am resolving as not eclipse. I was able to reproduce the issue with an environment provided by Brian and was able to confirm that some (non-eclipse) resolver hook is hiding a system.bundle package from the surrogate bundle for the application. You will need to fix this resolver hook so that it does not do this. Reopening bug. I had a look at the resolver hook in question and it does appear there is an issue in the framework which we can address to help with this issue. The system bundle exports are not providing accurate attribute values for the bundle-symbolic-name attribute key. Currently it only has a single value of org.eclipse.osgi for the sustem bundle's symbolic name. It should use a collection so that it can include the alieas value of system.bundle. Created attachment 209231 [details]
possible fix
Here is a possible fix.
I released the patch to master with commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=1d44655e23034efd02c0d9a80202742d9b7b0dbc |