[
https://issues.apache.org/jira/browse/FELIX-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020969#comment-13020969
]
Stuart McCulloch commented on FELIX-2918:
-----------------------------------------
FWIW, Guice 3.0 does not do any dynamic loading unless you are using some sort
of AOP such as method interception - and even then it should use the
appropriate class loader as described above. Similarly the Peaberry generated
proxy (which proxies a single type) should use the appropriate class loader -
but the description also mentions using the "multiple()" service injection, in
which case a proxy is never created since it just provides an implementation of
the Iterable API..
Yuri, can you repeat your test with Guice 3.0 if you haven't already? Also if
you could attach/send some sort of testcase that we could run locally that
would be very useful.
> Missing package in Import-Package causes NoClassDefFoundError at runtime
> ------------------------------------------------------------------------
>
> Key: FELIX-2918
> URL: https://issues.apache.org/jira/browse/FELIX-2918
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-2.3.4
> Environment: OSX Snow Leopard, Maven3, Java6, Guice/Peaberry
> Reporter: Yuri
> Priority: Minor
>
> I have an issue where I get a NoClassDefFoundError while starting my
> multi-project bundles. This exception is thrown while Peaberry is creating an
> proxy for a multiple() import. Aside from the Peaberry specifics, the
> multiple() import is loading the service interface, it's implementation and
> dependencies until it hits this error. After taking a closer look and
> comparing the bundle giving me grief to another similar (wrt dependencies)
> one that was working fine, I noticed two differences in the Manifest: a
> missing package in the Import-Package and the same package missing from the
> uses directive in the Export-Package. Basically, maven-bundle-plugin was not
> "seeing" the missing package when auto generating the manifest.
> The scenario, in more detail, is as follows.
> Bundle A (the one with the missing package in the manifest) imports packages
> from bundle E:
> BUNDLE A (package a):
> --------
> interface a.AS extends e.ES<a.AS,a.AW>{}
> interface a.AW extends e.EW<a.AS,a.AW>{}
> BUNDLE E (packages e and b):
> --------
> interface e.EW<S extends e.ES<S,W>, W extends e.EW<S,W>> extends b.AD, b.AH{}
> interface b.AD{} // THIS IS THE NoClassDefFoundError CLASS
> interface b.AH{}
> I then ran my mvn3 build with maven-bundle-plugin v2.3.4 and attached a
> debugger to it. I then stopped in the aQute.lib.osgi.Analyzer line
> 1684 (t.addAll(clazz.getReferred());) for class a.AS. I was expecting
> to see packages a (for a.AS and the two generic parameters a.AS and
> a.AW, which happens to be in the same package), e (for e.ES interface,
> and the two generic parameters a.ES and e.EW, which happens to be in
> the same package) and b (b.AD and b.AH). However, I didn't see the
> package b there.
> So it seems that BND is not analyzing dependencies of dependencies and the
> reason my other module worked was because there was an unrelated, direct
> dependency to package b somewhere else, forcing the package to be added to
> the Manifest.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
