Return-Path: Delivered-To: apmail-incubator-felix-dev-archive@www.apache.org Received: (qmail 45469 invoked from network); 7 Dec 2006 12:52:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Dec 2006 12:52:46 -0000 Received: (qmail 40840 invoked by uid 500); 7 Dec 2006 12:52:53 -0000 Delivered-To: apmail-incubator-felix-dev-archive@incubator.apache.org Received: (qmail 40808 invoked by uid 500); 7 Dec 2006 12:52:53 -0000 Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: felix-dev@incubator.apache.org Delivered-To: mailing list felix-dev@incubator.apache.org Received: (qmail 40797 invoked by uid 99); 7 Dec 2006 12:52:53 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Dec 2006 04:52:53 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [209.85.132.242] (HELO an-out-0708.google.com) (209.85.132.242) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Dec 2006 04:52:42 -0800 Received: by an-out-0708.google.com with SMTP id b2so22978ana for ; Thu, 07 Dec 2006 04:52:21 -0800 (PST) Received: by 10.78.127.3 with SMTP id z3mr1439141huc.1165495940223; Thu, 07 Dec 2006 04:52:20 -0800 (PST) Received: by 10.78.144.3 with HTTP; Thu, 7 Dec 2006 04:52:20 -0800 (PST) Message-ID: Date: Thu, 7 Dec 2006 13:52:20 +0100 From: "=?ISO-8859-1?Q?Emil_Eifr=E9m?=" To: felix-dev@incubator.apache.org Subject: Re: Re-wire Case [was; Re; Bundle plugin: Importing packages from non-bundles] In-Reply-To: <200612071011.18490.niclas@hedhman.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4577190B.7010107@ungoverned.org> <200612071011.18490.niclas@hedhman.org> X-Virus-Checked: Checked by ClamAV on apache.org On 12/7/06, Niclas Hedhman 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