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)"). 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
