Re-wire Case [was; Re; Bundle plugin: Importing packages from non-bundles]

[Niclas Hedhman <ni...@hedhman.org>]

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

Re: Re[2]: Re-wire Case [was; Re; Bundle plugin: Importing packages from non-bundles]

[Emil Eifrém <em...@eifrem.com>]

On 12/7/06, Peter Kriens <Pe...@aqute.biz> wrote:
> It is not ambiguous because if an Import-Package can not be matched
> the bundle can not be resolved. You can make an imported package
> optional, in that case it will resolve but the import is ignored at
> resolve time (it will not be wired) and the internal packages will be
> used according to the description.
>
> So the premise that you can resolve with an unmatched import is not
> right. The description you quote assumes the bundle is resolved
> otherwise no classes are loaded from it.

Makes perfect sense. Thanks.

-EE

Re[2]: Re-wire Case [was; Re; Bundle plugin: Importing packages from non-bundles]

[Peter Kriens <Pe...@aQute.biz>]

It is not ambiguous because if an Import-Package can not be matched
the bundle can not be resolved. You can make an imported package
optional, in that case it will resolve but the import is ignored at
resolve time (it will not be wired) and the internal packages will be
used according to the description.

So the premise that you can resolve with an unmatched import is not
right. The description you quote assumes the bundle is resolved
otherwise no classes are loaded from it.

Kind regards,

     Peter Kriens
     




EE> On 12/7/06, Niclas Hedhman <ni...@hedhman.org> wrote:
>> 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.

EE> I read it over last night and came to the conclusion that it
EE> terminates in step 3:

EE> "If the class or resource is in a package that is imported using Import-
EE> Package or was imported dynamically in a previous load, then the
EE> request is delegated to the exporting bundle's class loader; otherwise the
EE> search continues with the next step." (3.8.4, step 3)

EE> I re-read it with fresh(er) eyes and now I think it's ambiguous. It
EE> doesn't explicitly say how to handle Import-Packages that can't be
EE> matched to Export-Packages (I read the "otherwise" clause to be
EE> attached to "if Import-Package" not to "if found(Export-Package)").

EE> I ran a test on Knopflerfish (sorry) and they terminate in 3 (rejects
EE> the bundle with a BundleException because of missing or unresolved
EE> packages). It seems like the reasonable thing to do since it avoids
EE> your indeterministic scenario. Furthermore, it seems more analogous
EE> with (my understanding of) embedded or inlined jars: "Framework, from
EE> this point of view I'm an autonomous bundle. Don't you worry about
EE> these particular dependencies."

EE> Cheers,

EE> -EE

-- 
Peter Kriens                              Tel +33467542167
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599

Re: Re-wire Case [was; Re; Bundle plugin: Importing packages from non-bundles]

["Richard S. Hall" <he...@ungoverned.org>]

Emil Eifrém wrote:
> On 12/7/06, Niclas Hedhman <ni...@hedhman.org> wrote:
>> 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.
>
> I read it over last night and came to the conclusion that it
> terminates in step 3:
>
> "If the class or resource is in a package that is imported using Import-
> Package or was imported dynamically in a previous load, then the
> request is delegated to the exporting bundle's class loader; otherwise 
> the
> search continues with the next step." (3.8.4, step 3)
>
> I re-read it with fresh(er) eyes and now I think it's ambiguous. It
> doesn't explicitly say how to handle Import-Packages that can't be
> matched to Export-Packages (I read the "otherwise" clause to be
> attached to "if Import-Package" not to "if found(Export-Package)").

If an import cannot be matched to an export then the bundle doesn't 
resolve and you cannot load classes from it (nor activate it) no matter 
what.

If the import is optional, then the import will be ignored by the 
resolver forever if not found at resolve time. Then the bundle can get 
an internal version of the package if present.

If the import is dynamic, then the import will be ignored until the 
bundle tries to load it at run time. At which point the framework will 
try to resolve the import. If the bundle has an internal version of the 
package, then the dynamic import will never happen because the internal 
package will always be found first.

> I ran a test on Knopflerfish (sorry) and they terminate in 3 (rejects
> the bundle with a BundleException because of missing or unresolved
> packages). It seems like the reasonable thing to do since it avoids
> your indeterministic scenario. Furthermore, it seems more analogous
> with (my understanding of) embedded or inlined jars: "Framework, from
> this point of view I'm an autonomous bundle. Don't you worry about
> these particular dependencies."

This is exactly how Felix should behave too...let me know if you 
discover otherwise.

-> richard

>
> Cheers,
>
> -EE

Re: Re-wire Case [was; Re; Bundle plugin: Importing packages from non-bundles]

[Emil Eifrém <em...@eifrem.com>]

On 12/7/06, Niclas Hedhman <ni...@hedhman.org> wrote:
> 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.

I read it over last night and came to the conclusion that it
terminates in step 3:

"If the class or resource is in a package that is imported using Import-
Package or was imported dynamically in a previous load, then the
request is delegated to the exporting bundle's class loader; otherwise the
search continues with the next step." (3.8.4, step 3)

I re-read it with fresh(er) eyes and now I think it's ambiguous. It
doesn't explicitly say how to handle Import-Packages that can't be
matched to Export-Packages (I read the "otherwise" clause to be
attached to "if Import-Package" not to "if found(Export-Package)").

I ran a test on Knopflerfish (sorry) and they terminate in 3 (rejects
the bundle with a BundleException because of missing or unresolved
packages). It seems like the reasonable thing to do since it avoids
your indeterministic scenario. Furthermore, it seems more analogous
with (my understanding of) embedded or inlined jars: "Framework, from
this point of view I'm an autonomous bundle. Don't you worry about
these particular dependencies."

Cheers,

-EE