On Thursday 07 December 2006 03:24, Richard S. Hall wrote: > Emil Eifrém wrote: > > Hmm, then I'm mistaken about some OSGi fundamentals. I thought the > > framework matched my bundle's Import-Packages to other bundles > > Export-Packages. In this case, I don't want the framework to find a > > bundle that provides the package since the package is provided by the > > (plain, non-bundle) embedded jar on the Bundle-Classpath. That's why I > > thought the plugin shouldn't add the package to the Import-Package > > statement. > > > > Is this an incorrect understanding of how OSGi works?
Well, AFAIU, it seems legal to have Import-Package of classes that are available internal to the bundle (see 3.8.4), and still have it resolved even if there is no Export-Package in the system. That makes little sense to me, but more importantly I think it opens up a bit of indeterministic behaviour; 1. Bundle A loads and refers to class C in package P, which is found internally in the system. It has Import-Package: P but no Export-Package. 2. Bundle B loads and has Export-Package: P Bundle A must now be stopped and re-wired to Bundle B's export. Otherwise, if a third bundle imports P and gets hold of C (e.g. via a service) a ClassCastException will occur. But if 2. preceeds 1. in time, then no problem will occur. Right? So, does Felix re-wire all Import-Package when a Export-Package appears in the system, i.e. even running bundles? Cheers Niclas
