Emil Eifrém wrote:
On 12/7/06, Niclas Hedhman <[EMAIL PROTECTED]> 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
