felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-2918) Missing package in Import-Package causes NoClassDefFoundError at runtime
Date Mon, 18 Apr 2011 10:52:05 GMT

    [ 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
> 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,
> 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

View raw message