You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Sahoo <Sa...@Sun.COM> on 2009/09/25 11:08:30 UTC
Question regarding package resolution
Can anyone tell what is the correct behavior in the scenario described
below?
Q1:
Bundle b1
Export-Package: p; uses:=q; version=1.0, q; version=1.0
Import-Package: p; q; version=1.0
Bundle b2
Export-Package: q; version=1.0
Import-Package: q; version=1.0
When b1 is being attempted to resolve, b2 is in INSTALLED state. Which
bundle will bundle b1 be wired to for package q? Does it depend on the
order of installation of bundles?
Q2:
What happens if I change bundle b1 to have a DynamicImport-Package for
package q?
My objective is to not cause b2 to be resolved unnecessarily, hence the
question.
Thanks,
Sahoo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Question regarding package resolution
Posted by Guillaume Nodet <gn...@gmail.com>.
I don't think the behavior is specified by the spec.
When a bundle export / import the same package, which is the case for
b1, the framework is free to choose that the bundle will either export
*or* import the package.
If the package is exported, then b2 should not have to be resolved,
but if the framework decides to import the package, b2 will have to.
The important point is that afaik, you can't be sure.
On Fri, Sep 25, 2009 at 11:08, Sahoo <Sa...@sun.com> wrote:
> Can anyone tell what is the correct behavior in the scenario described
> below?
>
> Q1:
> Bundle b1
> Export-Package: p; uses:=q; version=1.0, q; version=1.0
> Import-Package: p; q; version=1.0
>
> Bundle b2
> Export-Package: q; version=1.0
> Import-Package: q; version=1.0
>
> When b1 is being attempted to resolve, b2 is in INSTALLED state. Which
> bundle will bundle b1 be wired to for package q? Does it depend on the order
> of installation of bundles?
>
> Q2:
> What happens if I change bundle b1 to have a DynamicImport-Package for
> package q?
>
> My objective is to not cause b2 to be resolved unnecessarily, hence the
> question.
>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Question regarding package resolution
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 9/29/09 6:47, Sahoo wrote:
> Richard S. Hall wrote:
>> On 9/25/09 19:28, Sahoo wrote:
>>> [Writing this email so that someone reading this later gets the
>>> correct information. ]
>>> I had a lengthy offline discussion with Richard and the conclusion
>>> was because of the way Felix resolver is currently implemented,
>>> bundle b1 will get package q from itself for Q1 irrespective of
>>> installation order of b1 and b2 as long as b2 is in INSTALLED state.
>>
>> Did I say that? Maybe I was confused, since I am not sure its true.
>>
>> I think installation order is important since it is used for
>> priority. If we assume all bundles are INSTALLED and we are resolving
>> b1, p will be resolved to b1 since there is no other provider. For q,
>> however, there are two providers and the order of choice depends on
>> install order, since they are both version 1.0.
>>
>
> You mentioned that Felix starts with Export-Package list while
> resolving a bundle, so it has to first decide whether bundle b1 will
> export package q or not.
No, it is the opposite. When a bundle imports and exports the same
package, Felix always tries to resolve the import first (which may
resolve to itself). Sorry if I implied otherwise.
> If what you are now saying is correct, then what is implementation
> specific about this? What are the alternative ways of resolving those
> packages?
Yes, as I mentioned when we talked. The spec doesn't mandate that the
impl should favor imports over exports of the same package. That is the
impl's choice. Some could, as you say, favor exports over imports of the
same package.
I think in that scenario, if you favored exports you'd always end up
with b1 being resolved to itself, but by favoring imports it ends up
being dependent on installation order for q.
-> richard
>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Question regarding package resolution
Posted by Sahoo <Sa...@Sun.COM>.
Richard S. Hall wrote:
> On 9/25/09 19:28, Sahoo wrote:
>> [Writing this email so that someone reading this later gets the
>> correct information. ]
>> I had a lengthy offline discussion with Richard and the conclusion
>> was because of the way Felix resolver is currently implemented,
>> bundle b1 will get package q from itself for Q1 irrespective of
>> installation order of b1 and b2 as long as b2 is in INSTALLED state.
>
> Did I say that? Maybe I was confused, since I am not sure its true.
>
> I think installation order is important since it is used for priority.
> If we assume all bundles are INSTALLED and we are resolving b1, p will
> be resolved to b1 since there is no other provider. For q, however,
> there are two providers and the order of choice depends on install
> order, since they are both version 1.0.
>
You mentioned that Felix starts with Export-Package list while resolving
a bundle, so it has to first decide whether bundle b1 will export
package q or not.
If what you are now saying is correct, then what is implementation
specific about this? What are the alternative ways of resolving those
packages?
Thanks,
Sahoo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Question regarding package resolution
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 9/25/09 19:28, Sahoo wrote:
> [Writing this email so that someone reading this later gets the
> correct information. ]
> I had a lengthy offline discussion with Richard and the conclusion was
> because of the way Felix resolver is currently implemented, bundle b1
> will get package q from itself for Q1 irrespective of installation
> order of b1 and b2 as long as b2 is in INSTALLED state.
Did I say that? Maybe I was confused, since I am not sure its true.
I think installation order is important since it is used for priority.
If we assume all bundles are INSTALLED and we are resolving b1, p will
be resolved to b1 since there is no other provider. For q, however,
there are two providers and the order of choice depends on install
order, since they are both version 1.0.
-> richard
>
> Thanks,
> Sahoo
>
> Richard S. Hall wrote:
>> For Q1 there is no way to know for sure, the framework is free to
>> make the best decision. For Q2, bundles will not be allowed to
>> dynamically import packages they export.
>>
>> -> richard
>> Sahoo <Sa...@Sun.COM> wrote:
>>
>>> Can anyone tell what is the correct behavior in the scenario
>>> described below?
>>>
>>> Q1:
>>> Bundle b1
>>> Export-Package: p; uses:=q; version=1.0, q; version=1.0
>>> Import-Package: p; q; version=1.0
>>>
>>> Bundle b2
>>> Export-Package: q; version=1.0
>>> Import-Package: q; version=1.0
>>>
>>> When b1 is being attempted to resolve, b2 is in INSTALLED state.
>>> Which bundle will bundle b1 be wired to for package q? Does it
>>> depend on the order of installation of bundles?
>>>
>>> Q2:
>>> What happens if I change bundle b1 to have a DynamicImport-Package
>>> for package q?
>>>
>>> My objective is to not cause b2 to be resolved unnecessarily, hence
>>> the question.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Question regarding package resolution
Posted by Sahoo <Sa...@Sun.COM>.
[Writing this email so that someone reading this later gets the correct
information. ]
I had a lengthy offline discussion with Richard and the conclusion was
because of the way Felix resolver is currently implemented, bundle b1
will get package q from itself for Q1 irrespective of installation order
of b1 and b2 as long as b2 is in INSTALLED state.
Thanks,
Sahoo
Richard S. Hall wrote:
> For Q1 there is no way to know for sure, the framework is free to make the best decision. For Q2, bundles will not be allowed to dynamically import packages they export.
>
> -> richard
>
> Sahoo <Sa...@Sun.COM> wrote:
>
>
>> Can anyone tell what is the correct behavior in the scenario described
>> below?
>>
>> Q1:
>> Bundle b1
>> Export-Package: p; uses:=q; version=1.0, q; version=1.0
>> Import-Package: p; q; version=1.0
>>
>> Bundle b2
>> Export-Package: q; version=1.0
>> Import-Package: q; version=1.0
>>
>> When b1 is being attempted to resolve, b2 is in INSTALLED state. Which
>> bundle will bundle b1 be wired to for package q? Does it depend on the
>> order of installation of bundles?
>>
>> Q2:
>> What happens if I change bundle b1 to have a DynamicImport-Package for
>> package q?
>>
>> My objective is to not cause b2 to be resolved unnecessarily, hence the
>> question.
>>
>> Thanks,
>> Sahoo
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Question regarding package resolution
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 9/25/09 16:29, Guillaume Nodet wrote:
> Then, the next question is: is there any drawback in using dynamic
> imports instead of optional imports ?
> If this avoid the need for refreshing whithout too much overhead, that
> would be fine.
> I guess it would consume a bit more cpu when each time a class is
> trying to be loaded while the package is not wired. Anything else in
> mind ?
>
I think that is the main consideration, it will take a little longer
when you ask for the class and it is not there, but you are likely
catching a CNFE anyway, so it is probably not super quick to begin with.
Once you can a dynamic wire, then it is the same as any normal wire.
-> richard
> On Fri, Sep 25, 2009 at 16:22, Richard S. Hall<he...@ungoverned.org> wrote:
>
>> On 9/25/09 15:54, Guillaume Nodet wrote:
>>
>>> So what about if you import something optionally and add a dynamic
>>> import at the same time ?
>>> Is that allowed ?
>>> The goal would be to wire early if possible, but wire lately
>>> (dynamically) if not ...
>>> That would avoid refreshing the bundle if a bundle solving an optional
>>> import is later installed.
>>>
>>>
>> Isn't that what you can use dynamic imports for in the first place? I am not
>> sure you add any expressive capability by being able to optionally import
>> and dynamically import the same package at the same time.
>>
>> To answer your question, though, I am not exactly sure how we handle this
>> corner case. If we look at the wires, then it would be allowed. If we look
>> at the metadata, then it would not.
>>
>> -> richard
>>
>>
>>> On Fri, Sep 25, 2009 at 15:50, Richard S. Hall<he...@ungoverned.org>
>>> wrote:
>>>
>>>
>>>> On 9/25/09 11:44, Marcel Offermans wrote:
>>>>
>>>>
>>>>> On Sep 25, 2009, at 11:35 , Richard S. Hall wrote:
>>>>>
>>>>>
>>>>>
>>>>>> For Q2, bundles will not be allowed to dynamically import packages they
>>>>>> export.
>>>>>>
>>>>>>
>>>>> Does this actually mean that the framework will refuse to install or
>>>>> resolve such bundles?
>>>>>
>>>>>
>>>> No, it means the framework will not allow it to create a dynamic wire for
>>>> those packages. If it exports it, that's all it will ever do. You can
>>>> only
>>>> dynamically import something you do not import, export, or require
>>>> already.
>>>> But it is not an install error to do so, just an unreachable condition.
>>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>>> Greetings, Marcel
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Question regarding package resolution
Posted by Guillaume Nodet <gn...@gmail.com>.
Then, the next question is: is there any drawback in using dynamic
imports instead of optional imports ?
If this avoid the need for refreshing whithout too much overhead, that
would be fine.
I guess it would consume a bit more cpu when each time a class is
trying to be loaded while the package is not wired. Anything else in
mind ?
On Fri, Sep 25, 2009 at 16:22, Richard S. Hall <he...@ungoverned.org> wrote:
> On 9/25/09 15:54, Guillaume Nodet wrote:
>>
>> So what about if you import something optionally and add a dynamic
>> import at the same time ?
>> Is that allowed ?
>> The goal would be to wire early if possible, but wire lately
>> (dynamically) if not ...
>> That would avoid refreshing the bundle if a bundle solving an optional
>> import is later installed.
>>
>
> Isn't that what you can use dynamic imports for in the first place? I am not
> sure you add any expressive capability by being able to optionally import
> and dynamically import the same package at the same time.
>
> To answer your question, though, I am not exactly sure how we handle this
> corner case. If we look at the wires, then it would be allowed. If we look
> at the metadata, then it would not.
>
> -> richard
>
>> On Fri, Sep 25, 2009 at 15:50, Richard S. Hall<he...@ungoverned.org>
>> wrote:
>>
>>>
>>> On 9/25/09 11:44, Marcel Offermans wrote:
>>>
>>>>
>>>> On Sep 25, 2009, at 11:35 , Richard S. Hall wrote:
>>>>
>>>>
>>>>>
>>>>> For Q2, bundles will not be allowed to dynamically import packages they
>>>>> export.
>>>>>
>>>>
>>>> Does this actually mean that the framework will refuse to install or
>>>> resolve such bundles?
>>>>
>>>
>>> No, it means the framework will not allow it to create a dynamic wire for
>>> those packages. If it exports it, that's all it will ever do. You can
>>> only
>>> dynamically import something you do not import, export, or require
>>> already.
>>> But it is not an install error to do so, just an unreachable condition.
>>>
>>> -> richard
>>>
>>>
>>>>
>>>> Greetings, Marcel
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Question regarding package resolution
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 9/25/09 15:54, Guillaume Nodet wrote:
> So what about if you import something optionally and add a dynamic
> import at the same time ?
> Is that allowed ?
> The goal would be to wire early if possible, but wire lately
> (dynamically) if not ...
> That would avoid refreshing the bundle if a bundle solving an optional
> import is later installed.
>
Isn't that what you can use dynamic imports for in the first place? I am
not sure you add any expressive capability by being able to optionally
import and dynamically import the same package at the same time.
To answer your question, though, I am not exactly sure how we handle
this corner case. If we look at the wires, then it would be allowed. If
we look at the metadata, then it would not.
-> richard
> On Fri, Sep 25, 2009 at 15:50, Richard S. Hall<he...@ungoverned.org> wrote:
>
>> On 9/25/09 11:44, Marcel Offermans wrote:
>>
>>> On Sep 25, 2009, at 11:35 , Richard S. Hall wrote:
>>>
>>>
>>>> For Q2, bundles will not be allowed to dynamically import packages they
>>>> export.
>>>>
>>> Does this actually mean that the framework will refuse to install or
>>> resolve such bundles?
>>>
>> No, it means the framework will not allow it to create a dynamic wire for
>> those packages. If it exports it, that's all it will ever do. You can only
>> dynamically import something you do not import, export, or require already.
>> But it is not an install error to do so, just an unreachable condition.
>>
>> -> richard
>>
>>
>>> Greetings, Marcel
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Question regarding package resolution
Posted by Guillaume Nodet <gn...@gmail.com>.
So what about if you import something optionally and add a dynamic
import at the same time ?
Is that allowed ?
The goal would be to wire early if possible, but wire lately
(dynamically) if not ...
That would avoid refreshing the bundle if a bundle solving an optional
import is later installed.
On Fri, Sep 25, 2009 at 15:50, Richard S. Hall <he...@ungoverned.org> wrote:
> On 9/25/09 11:44, Marcel Offermans wrote:
>>
>> On Sep 25, 2009, at 11:35 , Richard S. Hall wrote:
>>
>>> For Q2, bundles will not be allowed to dynamically import packages they
>>> export.
>>
>> Does this actually mean that the framework will refuse to install or
>> resolve such bundles?
>
> No, it means the framework will not allow it to create a dynamic wire for
> those packages. If it exports it, that's all it will ever do. You can only
> dynamically import something you do not import, export, or require already.
> But it is not an install error to do so, just an unreachable condition.
>
> -> richard
>
>>
>> Greetings, Marcel
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Question regarding package resolution
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 9/25/09 11:44, Marcel Offermans wrote:
> On Sep 25, 2009, at 11:35 , Richard S. Hall wrote:
>
>> For Q2, bundles will not be allowed to dynamically import packages
>> they export.
>
> Does this actually mean that the framework will refuse to install or
> resolve such bundles?
No, it means the framework will not allow it to create a dynamic wire
for those packages. If it exports it, that's all it will ever do. You
can only dynamically import something you do not import, export, or
require already. But it is not an install error to do so, just an
unreachable condition.
-> richard
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Question regarding package resolution
Posted by Marcel Offermans <ma...@luminis.nl>.
On Sep 25, 2009, at 11:35 , Richard S. Hall wrote:
> For Q2, bundles will not be allowed to dynamically import packages
> they export.
Does this actually mean that the framework will refuse to install or
resolve such bundles?
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org