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 17:10:06 GMT

    [ https://issues.apache.org/jira/browse/FELIX-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021115#comment-13021115
] 

Stuart McCulloch commented on FELIX-2918:
-----------------------------------------

Actually I mis-spoke about the multiple() case in Peaberry - it does in fact create thin proxies
around the individual elements, so there could potentially be an issue with the ImportProxyClassLoader
(although it does delegate to the classloader of the type being proxied, so it should still
find the same dependent types). I think we really need a testcase to analyze this further
though. Note it doesn't have to be minimal, just as long as it's something I can test locally
(even binary bundles are ok) - feel free to email it directly to me (mcculls) if you don't
want to attach it to the issue.

> 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

Mime
View raw message