You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by David Jencks <da...@yahoo.com> on 2011/12/04 09:27:56 UTC
Blueprint org.osgi.service.blueprint export
I believe at the moment the blueprint api bundle is exporting org.osgi.service.blueprint, and the core bundle is also exporting it at version 1.0.0. (the all-in-one bundle is too, but I'm less worried about it)
I think the relevant part of the spec is 121.13.5:
To mitigate type incompatibility problems, a Blueprint extender must export the org.osgi.service.blueprint package. In the uses: directive, it should list any packages of classes that can be shared between the Blueprint extender and the Blueprint bundle. Blueprint bundles should import this package.
I think this means
1. the api bundle should not export this package
2. the core bundle should have a big uses clause. I'm not sure what should be in the uses clause. All the exports from the core bundle?
Obviously fixing this is trivial once we figure out what to do :-)
thanks
david jencks
Re: Blueprint org.osgi.service.blueprint export
Posted by Alasdair Nottingham <no...@apache.org>.
The uses should list the blueprint API packages.
On 5 December 2011 15:24, David Jencks <da...@yahoo.com> wrote:
> so...
>
> 1. That is explicitly contrary to the spec which says the _extender_
> bundle should export org.osgi.service.blueprint, not the api bundle.
>
> 2. As Guillaume has been telling me for a long time now, having the api
> bundle export this package completely subverts the purpose of having this
> package, of preventing two extenders from recognizing the same blueprint
> (using) bundle.
>
> The only way I can see to get the advantage of being able to update the
> blueprint-core bundle without reloading all the client blueprint bundle
> classes would be to put the extender code in a separate bundle from
> blueprint-core and including enough aries api in the extender bundle so the
> (currently missing) uses clauses won't always force reloading client
> blueprint bundles. IIUC refreshing blueprint core will still end up
> destroying and recreating all the blueprint containers.
>
> I also still want to know more about what the uses clause on the
> org.osgi.service.blueprint export should look like.
>
> thanks
> david jencks
>
> On Dec 5, 2011, at 5:50 AM, Timothy Ward wrote:
>
> >
> > One reason is to avoid installing support for the blueprint cm namespace
> - the uber bundle always contains that. Another reason is to allow you to
> update blueprint core without having to refresh every blueprint application
> bundle. By leaving the API installed the applications can remain started,
> and their blueprint containers will be gracefully shut down, then brought
> up by the new core bundle.
> >
> > Regards,
> >
> > Tim Ward
> > -------------------
> > Apache Aries PMC member & Enterprise OSGi advocate
> > Enterprise OSGi in Action (http://www.manning.com/cummins)
> > -------------------
> >
> >
> >> Subject: Re: Blueprint org.osgi.service.blueprint export
> >> From: david_jencks@yahoo.com
> >> Date: Sun, 4 Dec 2011 14:43:29 -0800
> >> To: dev@aries.apache.org
> >>
> >>
> >> On Dec 4, 2011, at 12:27 AM, David Jencks wrote:
> >>
> >>> I believe at the moment the blueprint api bundle is exporting
> org.osgi.service.blueprint, and the core bundle is also exporting it at
> version 1.0.0. (the all-in-one bundle is too, but I'm less worried about
> it)
> >>>
> >>> I think the relevant part of the spec is 121.13.5:
> >>>
> >>> To mitigate type incompatibility problems, a Blueprint extender must
> export the org.osgi.service.blueprint package. In the uses: directive, it
> should list any packages of classes that can be shared between the
> Blueprint extender and the Blueprint bundle. Blueprint bundles should
> import this package.
> >>>
> >>> I think this means
> >>>
> >>> 1. the api bundle should not export this package
> >>>
> >>> 2. the core bundle should have a big uses clause. I'm not sure what
> should be in the uses clause. All the exports from the core bundle?
> >>>
> >>> Obviously fixing this is trivial once we figure out what to do :-)
> >>
> >> On the karaf list Guillaume asked why using the little bundles is
> better than the all-in-one bundle, since if you refresh the blueprint core
> bundle which exports org.osgi.service.blueprint you're going to force a
> refresh of all the "application" blueprint bundles that are using aries
> blueprint core. At the moment I don't have a good answer, so I wonder if
> it would be better to put the extender itself in a separate bundle (not
> expected to be refreshed) and thus allow the rest of core to be refreshed.
> I guess this would mean the core functionality would be exposed through a
> service the extender uses. (I'm not sure how it works today).
> >>
> >> thoughts?
> >>
> >> thanks
> >> david jencks
> >>
> >>>
> >>> thanks
> >>> david jencks
> >>>
> >>
> >
>
>
--
Alasdair Nottingham
not@apache.org
Re: Blueprint org.osgi.service.blueprint export
Posted by David Jencks <da...@yahoo.com>.
so...
1. That is explicitly contrary to the spec which says the _extender_ bundle should export org.osgi.service.blueprint, not the api bundle.
2. As Guillaume has been telling me for a long time now, having the api bundle export this package completely subverts the purpose of having this package, of preventing two extenders from recognizing the same blueprint (using) bundle.
The only way I can see to get the advantage of being able to update the blueprint-core bundle without reloading all the client blueprint bundle classes would be to put the extender code in a separate bundle from blueprint-core and including enough aries api in the extender bundle so the (currently missing) uses clauses won't always force reloading client blueprint bundles. IIUC refreshing blueprint core will still end up destroying and recreating all the blueprint containers.
I also still want to know more about what the uses clause on the org.osgi.service.blueprint export should look like.
thanks
david jencks
On Dec 5, 2011, at 5:50 AM, Timothy Ward wrote:
>
> One reason is to avoid installing support for the blueprint cm namespace - the uber bundle always contains that. Another reason is to allow you to update blueprint core without having to refresh every blueprint application bundle. By leaving the API installed the applications can remain started, and their blueprint containers will be gracefully shut down, then brought up by the new core bundle.
>
> Regards,
>
> Tim Ward
> -------------------
> Apache Aries PMC member & Enterprise OSGi advocate
> Enterprise OSGi in Action (http://www.manning.com/cummins)
> -------------------
>
>
>> Subject: Re: Blueprint org.osgi.service.blueprint export
>> From: david_jencks@yahoo.com
>> Date: Sun, 4 Dec 2011 14:43:29 -0800
>> To: dev@aries.apache.org
>>
>>
>> On Dec 4, 2011, at 12:27 AM, David Jencks wrote:
>>
>>> I believe at the moment the blueprint api bundle is exporting org.osgi.service.blueprint, and the core bundle is also exporting it at version 1.0.0. (the all-in-one bundle is too, but I'm less worried about it)
>>>
>>> I think the relevant part of the spec is 121.13.5:
>>>
>>> To mitigate type incompatibility problems, a Blueprint extender must export the org.osgi.service.blueprint package. In the uses: directive, it should list any packages of classes that can be shared between the Blueprint extender and the Blueprint bundle. Blueprint bundles should import this package.
>>>
>>> I think this means
>>>
>>> 1. the api bundle should not export this package
>>>
>>> 2. the core bundle should have a big uses clause. I'm not sure what should be in the uses clause. All the exports from the core bundle?
>>>
>>> Obviously fixing this is trivial once we figure out what to do :-)
>>
>> On the karaf list Guillaume asked why using the little bundles is better than the all-in-one bundle, since if you refresh the blueprint core bundle which exports org.osgi.service.blueprint you're going to force a refresh of all the "application" blueprint bundles that are using aries blueprint core. At the moment I don't have a good answer, so I wonder if it would be better to put the extender itself in a separate bundle (not expected to be refreshed) and thus allow the rest of core to be refreshed. I guess this would mean the core functionality would be exposed through a service the extender uses. (I'm not sure how it works today).
>>
>> thoughts?
>>
>> thanks
>> david jencks
>>
>>>
>>> thanks
>>> david jencks
>>>
>>
>
Re: Blueprint org.osgi.service.blueprint export
Posted by Guillaume Nodet <gn...@gmail.com>.
That won't work are blueprint bundles are supposed to import the
org.osgi.service.blueprint package which is exported by the extender
implementation.
My concern is about splitting the api from the core which could cause
a second extender to wire against the same api, leading to the
inability to use the class-space to split the blueprint bundles
between the extenders (and avoid multiple extenders to extend the same
bundle).
On Mon, Dec 5, 2011 at 14:50, Timothy Ward <ti...@apache.org> wrote:
>
> One reason is to avoid installing support for the blueprint cm namespace - the uber bundle always contains that. Another reason is to allow you to update blueprint core without having to refresh every blueprint application bundle. By leaving the API installed the applications can remain started, and their blueprint containers will be gracefully shut down, then brought up by the new core bundle.
>
> Regards,
>
> Tim Ward
> -------------------
> Apache Aries PMC member & Enterprise OSGi advocate
> Enterprise OSGi in Action (http://www.manning.com/cummins)
> -------------------
>
>
>> Subject: Re: Blueprint org.osgi.service.blueprint export
>> From: david_jencks@yahoo.com
>> Date: Sun, 4 Dec 2011 14:43:29 -0800
>> To: dev@aries.apache.org
>>
>>
>> On Dec 4, 2011, at 12:27 AM, David Jencks wrote:
>>
>> > I believe at the moment the blueprint api bundle is exporting org.osgi.service.blueprint, and the core bundle is also exporting it at version 1.0.0. (the all-in-one bundle is too, but I'm less worried about it)
>> >
>> > I think the relevant part of the spec is 121.13.5:
>> >
>> > To mitigate type incompatibility problems, a Blueprint extender must export the org.osgi.service.blueprint package. In the uses: directive, it should list any packages of classes that can be shared between the Blueprint extender and the Blueprint bundle. Blueprint bundles should import this package.
>> >
>> > I think this means
>> >
>> > 1. the api bundle should not export this package
>> >
>> > 2. the core bundle should have a big uses clause. I'm not sure what should be in the uses clause. All the exports from the core bundle?
>> >
>> > Obviously fixing this is trivial once we figure out what to do :-)
>>
>> On the karaf list Guillaume asked why using the little bundles is better than the all-in-one bundle, since if you refresh the blueprint core bundle which exports org.osgi.service.blueprint you're going to force a refresh of all the "application" blueprint bundles that are using aries blueprint core. At the moment I don't have a good answer, so I wonder if it would be better to put the extender itself in a separate bundle (not expected to be refreshed) and thus allow the rest of core to be refreshed. I guess this would mean the core functionality would be exposed through a service the extender uses. (I'm not sure how it works today).
>>
>> thoughts?
>>
>> thanks
>> david jencks
>>
>> >
>> > thanks
>> > david jencks
>> >
>>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
RE: Blueprint org.osgi.service.blueprint export
Posted by Timothy Ward <ti...@apache.org>.
One reason is to avoid installing support for the blueprint cm namespace - the uber bundle always contains that. Another reason is to allow you to update blueprint core without having to refresh every blueprint application bundle. By leaving the API installed the applications can remain started, and their blueprint containers will be gracefully shut down, then brought up by the new core bundle.
Regards,
Tim Ward
-------------------
Apache Aries PMC member & Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------
> Subject: Re: Blueprint org.osgi.service.blueprint export
> From: david_jencks@yahoo.com
> Date: Sun, 4 Dec 2011 14:43:29 -0800
> To: dev@aries.apache.org
>
>
> On Dec 4, 2011, at 12:27 AM, David Jencks wrote:
>
> > I believe at the moment the blueprint api bundle is exporting org.osgi.service.blueprint, and the core bundle is also exporting it at version 1.0.0. (the all-in-one bundle is too, but I'm less worried about it)
> >
> > I think the relevant part of the spec is 121.13.5:
> >
> > To mitigate type incompatibility problems, a Blueprint extender must export the org.osgi.service.blueprint package. In the uses: directive, it should list any packages of classes that can be shared between the Blueprint extender and the Blueprint bundle. Blueprint bundles should import this package.
> >
> > I think this means
> >
> > 1. the api bundle should not export this package
> >
> > 2. the core bundle should have a big uses clause. I'm not sure what should be in the uses clause. All the exports from the core bundle?
> >
> > Obviously fixing this is trivial once we figure out what to do :-)
>
> On the karaf list Guillaume asked why using the little bundles is better than the all-in-one bundle, since if you refresh the blueprint core bundle which exports org.osgi.service.blueprint you're going to force a refresh of all the "application" blueprint bundles that are using aries blueprint core. At the moment I don't have a good answer, so I wonder if it would be better to put the extender itself in a separate bundle (not expected to be refreshed) and thus allow the rest of core to be refreshed. I guess this would mean the core functionality would be exposed through a service the extender uses. (I'm not sure how it works today).
>
> thoughts?
>
> thanks
> david jencks
>
> >
> > thanks
> > david jencks
> >
>
Re: Blueprint org.osgi.service.blueprint export
Posted by David Jencks <da...@yahoo.com>.
On Dec 4, 2011, at 12:27 AM, David Jencks wrote:
> I believe at the moment the blueprint api bundle is exporting org.osgi.service.blueprint, and the core bundle is also exporting it at version 1.0.0. (the all-in-one bundle is too, but I'm less worried about it)
>
> I think the relevant part of the spec is 121.13.5:
>
> To mitigate type incompatibility problems, a Blueprint extender must export the org.osgi.service.blueprint package. In the uses: directive, it should list any packages of classes that can be shared between the Blueprint extender and the Blueprint bundle. Blueprint bundles should import this package.
>
> I think this means
>
> 1. the api bundle should not export this package
>
> 2. the core bundle should have a big uses clause. I'm not sure what should be in the uses clause. All the exports from the core bundle?
>
> Obviously fixing this is trivial once we figure out what to do :-)
On the karaf list Guillaume asked why using the little bundles is better than the all-in-one bundle, since if you refresh the blueprint core bundle which exports org.osgi.service.blueprint you're going to force a refresh of all the "application" blueprint bundles that are using aries blueprint core. At the moment I don't have a good answer, so I wonder if it would be better to put the extender itself in a separate bundle (not expected to be refreshed) and thus allow the rest of core to be refreshed. I guess this would mean the core functionality would be exposed through a service the extender uses. (I'm not sure how it works today).
thoughts?
thanks
david jencks
>
> thanks
> david jencks
>