You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Timothy Ward <ti...@hotmail.com> on 2010/09/23 12:29:04 UTC
Auto-generation of Import-Service and Export-Service
Hi,
There are some problems with the way in which Aries models bundles for resolution in OBR. Currently we look at the blueprint for imported and exported services, but also fall back to the Import-Service and Export-Service headers in case there are any legacy bundles.
Unfortunately it seems as though all of our bundles have Import-Service and Export-Service headers generated (using non-standard directives and attributes to boot). This means that we duplicate service imports and exports in our OBR model, which is a major performance concern, but worse, the headers are interpreted differently.
ARIES-425 was caused by the fact that the duplicate Import-Service header caused an optional blueprint service to also be found as a mandatory Import-Service. Where are these non-standard, deprecated headers coming from and how can we turn them off?
Regards,
Tim
Re: Auto-generation of Import-Service and Export-Service
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Sep 23, 2010 at 14:51, Guillaume Nodet <gn...@gmail.com> wrote:
> That was a long time ago. I thought the generation of those headers
> had been removed since.
I was wrong, I was thinking about the additional package / service
imports generated for blueprint custom namespace handlers.
> Maybe it has only been removed for some maven modules and not in all places ...
>
> What is the 'something better based on blueprint' you are talking about ?
>
> On Thu, Sep 23, 2010 at 13:07, Mark Nuttall <mn...@apache.org> wrote:
>> We talked about this previously back in February in the thread 'Re: [jira]
>> Resolved: (ARIES-197) Fix the Export-Service / Import-Service headers.'
>> Guillaume wrote,
>>
>> I do agree those headers are mostly useful for the OBR capabilities
>> generation.
>> I'd be more than happy to remove them once we have something better based on
>> blueprint.
>> In the mean time, I think it's quite harmless to keep them in. They really
>> help when generating OBR requirements, so that in Karaf, i can simply write
>> the following command:
>> obr:start "Apache Aries Application Management"
>>
>>
>> I think it's time to take these headers out. We do now have something better
>> based on blueprint. The headers are not harmless since the service-based
>> provisioning code parses them. They contain non-standard values which we
>> cannot be certain to parse correctly in all cases.
>>
>> Regards,
>> Mark
>>
>> On 23 September 2010 11:29, Timothy Ward <ti...@hotmail.com> wrote:
>>
>>>
>>> Hi,
>>>
>>> There are some problems with the way in which Aries models bundles for
>>> resolution in OBR. Currently we look at the blueprint for imported and
>>> exported services, but also fall back to the Import-Service and
>>> Export-Service headers in case there are any legacy bundles.
>>>
>>> Unfortunately it seems as though all of our bundles have Import-Service and
>>> Export-Service headers generated (using non-standard directives and
>>> attributes to boot). This means that we duplicate service imports and
>>> exports in our OBR model, which is a major performance concern, but worse,
>>> the headers are interpreted differently.
>>>
>>> ARIES-425 was caused by the fact that the duplicate Import-Service header
>>> caused an optional blueprint service to also be found as a mandatory
>>> Import-Service. Where are these non-standard, deprecated headers coming from
>>> and how can we turn them off?
>>>
>>> Regards,
>>>
>>> Tim
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Auto-generation of Import-Service and Export-Service
Posted by Guillaume Nodet <gn...@gmail.com>.
If I get things right, the prerequisite is to use Aries applications
(and maybe blueprint).
What about people who don't ?
I'd still rather fix any issue with the current headers and then
switch to using Generic capabilities when the spec is out (see the
last published draft of the OSGi Alliance).
On Thu, Sep 23, 2010 at 15:14, Mark Nuttall <mn...@apache.org> wrote:
> Hi Guillaume.
>> I thought the generation of those headers had been removed since.
>
> Is that to say that you're no longer using these headers?
>
>> What is the 'something better based on blueprint' you are talking about ?
>
> Emily Jiang's recent contributions under ARIES-361 include extensions to OBR
> that enable the OBRAriesResolver to provision against service dependencies
> inferred from individual bundles' <service> and <reference> blueprint
> elements.
>
> We don't yet have a standalone tool (like an extended bindex) that will
> produce the necessary repository.xml, but the code to do so can be found in
> the generateOBRRepoXML() method of OBRResolverAdvancedTest.java.
>
> Regards,
> Mark
>
> On 23 September 2010 13:51, Guillaume Nodet <gn...@gmail.com> wrote:
>
>> That was a long time ago. I thought the generation of those headers
>> had been removed since.
>> Maybe it has only been removed for some maven modules and not in all places
>> ...
>>
>> What is the 'something better based on blueprint' you are talking about ?
>>
>> On Thu, Sep 23, 2010 at 13:07, Mark Nuttall <mn...@apache.org> wrote:
>> > We talked about this previously back in February in the thread 'Re:
>> [jira]
>> > Resolved: (ARIES-197) Fix the Export-Service / Import-Service headers.'
>> > Guillaume wrote,
>> >
>> > I do agree those headers are mostly useful for the OBR capabilities
>> > generation.
>> > I'd be more than happy to remove them once we have something better based
>> on
>> > blueprint.
>> > In the mean time, I think it's quite harmless to keep them in. They
>> really
>> > help when generating OBR requirements, so that in Karaf, i can simply
>> write
>> > the following command:
>> > obr:start "Apache Aries Application Management"
>> >
>> >
>> > I think it's time to take these headers out. We do now have something
>> better
>> > based on blueprint. The headers are not harmless since the service-based
>> > provisioning code parses them. They contain non-standard values which we
>> > cannot be certain to parse correctly in all cases.
>> >
>> > Regards,
>> > Mark
>> >
>> > On 23 September 2010 11:29, Timothy Ward <ti...@hotmail.com>
>> wrote:
>> >
>> >>
>> >> Hi,
>> >>
>> >> There are some problems with the way in which Aries models bundles for
>> >> resolution in OBR. Currently we look at the blueprint for imported and
>> >> exported services, but also fall back to the Import-Service and
>> >> Export-Service headers in case there are any legacy bundles.
>> >>
>> >> Unfortunately it seems as though all of our bundles have Import-Service
>> and
>> >> Export-Service headers generated (using non-standard directives and
>> >> attributes to boot). This means that we duplicate service imports and
>> >> exports in our OBR model, which is a major performance concern, but
>> worse,
>> >> the headers are interpreted differently.
>> >>
>> >> ARIES-425 was caused by the fact that the duplicate Import-Service
>> header
>> >> caused an optional blueprint service to also be found as a mandatory
>> >> Import-Service. Where are these non-standard, deprecated headers coming
>> from
>> >> and how can we turn them off?
>> >>
>> >> Regards,
>> >>
>> >> Tim
>> >>
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Auto-generation of Import-Service and Export-Service
Posted by Mark Nuttall <mn...@apache.org>.
Hi Guillaume.
> I thought the generation of those headers had been removed since.
Is that to say that you're no longer using these headers?
> What is the 'something better based on blueprint' you are talking about ?
Emily Jiang's recent contributions under ARIES-361 include extensions to OBR
that enable the OBRAriesResolver to provision against service dependencies
inferred from individual bundles' <service> and <reference> blueprint
elements.
We don't yet have a standalone tool (like an extended bindex) that will
produce the necessary repository.xml, but the code to do so can be found in
the generateOBRRepoXML() method of OBRResolverAdvancedTest.java.
Regards,
Mark
On 23 September 2010 13:51, Guillaume Nodet <gn...@gmail.com> wrote:
> That was a long time ago. I thought the generation of those headers
> had been removed since.
> Maybe it has only been removed for some maven modules and not in all places
> ...
>
> What is the 'something better based on blueprint' you are talking about ?
>
> On Thu, Sep 23, 2010 at 13:07, Mark Nuttall <mn...@apache.org> wrote:
> > We talked about this previously back in February in the thread 'Re:
> [jira]
> > Resolved: (ARIES-197) Fix the Export-Service / Import-Service headers.'
> > Guillaume wrote,
> >
> > I do agree those headers are mostly useful for the OBR capabilities
> > generation.
> > I'd be more than happy to remove them once we have something better based
> on
> > blueprint.
> > In the mean time, I think it's quite harmless to keep them in. They
> really
> > help when generating OBR requirements, so that in Karaf, i can simply
> write
> > the following command:
> > obr:start "Apache Aries Application Management"
> >
> >
> > I think it's time to take these headers out. We do now have something
> better
> > based on blueprint. The headers are not harmless since the service-based
> > provisioning code parses them. They contain non-standard values which we
> > cannot be certain to parse correctly in all cases.
> >
> > Regards,
> > Mark
> >
> > On 23 September 2010 11:29, Timothy Ward <ti...@hotmail.com>
> wrote:
> >
> >>
> >> Hi,
> >>
> >> There are some problems with the way in which Aries models bundles for
> >> resolution in OBR. Currently we look at the blueprint for imported and
> >> exported services, but also fall back to the Import-Service and
> >> Export-Service headers in case there are any legacy bundles.
> >>
> >> Unfortunately it seems as though all of our bundles have Import-Service
> and
> >> Export-Service headers generated (using non-standard directives and
> >> attributes to boot). This means that we duplicate service imports and
> >> exports in our OBR model, which is a major performance concern, but
> worse,
> >> the headers are interpreted differently.
> >>
> >> ARIES-425 was caused by the fact that the duplicate Import-Service
> header
> >> caused an optional blueprint service to also be found as a mandatory
> >> Import-Service. Where are these non-standard, deprecated headers coming
> from
> >> and how can we turn them off?
> >>
> >> Regards,
> >>
> >> Tim
> >>
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Auto-generation of Import-Service and Export-Service
Posted by Guillaume Nodet <gn...@gmail.com>.
That was a long time ago. I thought the generation of those headers
had been removed since.
Maybe it has only been removed for some maven modules and not in all places ...
What is the 'something better based on blueprint' you are talking about ?
On Thu, Sep 23, 2010 at 13:07, Mark Nuttall <mn...@apache.org> wrote:
> We talked about this previously back in February in the thread 'Re: [jira]
> Resolved: (ARIES-197) Fix the Export-Service / Import-Service headers.'
> Guillaume wrote,
>
> I do agree those headers are mostly useful for the OBR capabilities
> generation.
> I'd be more than happy to remove them once we have something better based on
> blueprint.
> In the mean time, I think it's quite harmless to keep them in. They really
> help when generating OBR requirements, so that in Karaf, i can simply write
> the following command:
> obr:start "Apache Aries Application Management"
>
>
> I think it's time to take these headers out. We do now have something better
> based on blueprint. The headers are not harmless since the service-based
> provisioning code parses them. They contain non-standard values which we
> cannot be certain to parse correctly in all cases.
>
> Regards,
> Mark
>
> On 23 September 2010 11:29, Timothy Ward <ti...@hotmail.com> wrote:
>
>>
>> Hi,
>>
>> There are some problems with the way in which Aries models bundles for
>> resolution in OBR. Currently we look at the blueprint for imported and
>> exported services, but also fall back to the Import-Service and
>> Export-Service headers in case there are any legacy bundles.
>>
>> Unfortunately it seems as though all of our bundles have Import-Service and
>> Export-Service headers generated (using non-standard directives and
>> attributes to boot). This means that we duplicate service imports and
>> exports in our OBR model, which is a major performance concern, but worse,
>> the headers are interpreted differently.
>>
>> ARIES-425 was caused by the fact that the duplicate Import-Service header
>> caused an optional blueprint service to also be found as a mandatory
>> Import-Service. Where are these non-standard, deprecated headers coming from
>> and how can we turn them off?
>>
>> Regards,
>>
>> Tim
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Auto-generation of Import-Service and Export-Service
Posted by Mark Nuttall <mn...@apache.org>.
We talked about this previously back in February in the thread 'Re: [jira]
Resolved: (ARIES-197) Fix the Export-Service / Import-Service headers.'
Guillaume wrote,
I do agree those headers are mostly useful for the OBR capabilities
generation.
I'd be more than happy to remove them once we have something better based on
blueprint.
In the mean time, I think it's quite harmless to keep them in. They really
help when generating OBR requirements, so that in Karaf, i can simply write
the following command:
obr:start "Apache Aries Application Management"
I think it's time to take these headers out. We do now have something better
based on blueprint. The headers are not harmless since the service-based
provisioning code parses them. They contain non-standard values which we
cannot be certain to parse correctly in all cases.
Regards,
Mark
On 23 September 2010 11:29, Timothy Ward <ti...@hotmail.com> wrote:
>
> Hi,
>
> There are some problems with the way in which Aries models bundles for
> resolution in OBR. Currently we look at the blueprint for imported and
> exported services, but also fall back to the Import-Service and
> Export-Service headers in case there are any legacy bundles.
>
> Unfortunately it seems as though all of our bundles have Import-Service and
> Export-Service headers generated (using non-standard directives and
> attributes to boot). This means that we duplicate service imports and
> exports in our OBR model, which is a major performance concern, but worse,
> the headers are interpreted differently.
>
> ARIES-425 was caused by the fact that the duplicate Import-Service header
> caused an optional blueprint service to also be found as a mandatory
> Import-Service. Where are these non-standard, deprecated headers coming from
> and how can we turn them off?
>
> Regards,
>
> Tim
>
Re: Auto-generation of Import-Service and Export-Service
Posted by Guillaume Nodet <gn...@gmail.com>.
Well, feel free to submit a patch to change the headers in both the
bundle plugin and the bundle repository. As long as the information
is in the manifest and in the obr xml, I don't really care about the
names themselves. But that in this case, we'd have to also change the
aries application code to take those headers into account, as this is
the only way to support bundles not using Blueprint.
Also, looking at the current Aries code, it seems it handles nicely
the extended Import-Service syntax nicely with both the optional and
filter attributes (see the second constructor of ImportedServiceImpl),
though if it is (wrongly ?) marked as deprecated.
I really don't care about the name of those headers, but I really care
about the fact that they are used.
On Thu, Sep 23, 2010 at 16:47, Alasdair Nottingham <no...@apache.org> wrote:
> That is not the position the alliance takes on deprecated stuff. When they deprecated stuff they don't "cease" to specify it, they just stop putting it in specs. It is still specified as it was in the OSGi R3 spec.
>
> As I said back then if you want to do this you should be using non-standard headers, or get the Alliance to change the spec.
>
> Alasdair Nottingham
>
> On 23 Sep 2010, at 06:59, Guillaume Nodet <gn...@gmail.com> wrote:
>
>> Right, and they are deprecated, so their syntax isn't defined anymore
>> in the specs ;-)
>> So that's completely untrue to say those headers are non-compliant,
>> unless you plan to
>> deploy on an OSGi 3 platform, which Aries does not support.
>>
>> Given those headers are not used by the OSGi framework, I fail to see
>> what kind of
>> problems it could lead to.
>>
>> Also, the generation you are referring to (about the namespace
>> handlers additional service
>> imports) have been removed in all maven modules afaik.
>>
>> I'd be happy to actually fix anything in the generation as I said. If
>> the generated information
>> can't be mapped back to the blueprint services, there is actaully a
>> problem somewhere,
>> else the information generated by the application deployer and the
>> maven bundle plugin
>> should be the same.
>>
>> Please remember, Aries components might be consumed by means other than Aries
>> applications. Also, Aries applications can contains bundles based on
>> tools other than
>> Blueprint and the use of those headers is currently the only to have
>> this metadata available
>> for everyone.
>>
>>
>> On Thu, Sep 23, 2010 at 15:49, Mark Nuttall <mn...@apache.org> wrote:
>>> These deprecated headers were defined in the version 3 spec, section 4.14
>>>
>>>
>>> 4.14 Importing and Exporting Services
>>> The Export-Service manifest header declares the interfaces that a bundle
>>> may register. It provides advisory information that is not used by the
>>> Frame-
>>> work. This header is intended for use by server-side management tools.
>>> The Export-Service manifest header must conform to the following syntax:
>>>
>>>
>>> Export-Service ::= class-name ( ’,’ class-name )*
>>>
>>> class-name ::= <fully qualified class name>
>>>
>>>
>>> The Import-Service manifest header declares the interfaces the bundle may
>>> use. It provides advisory information that is not used by the Framework.
>>> This header is also intended for use by server-side management tools.
>>> The Import-Service manifest header must conform to the following syntax:
>>>
>>> Import-Service ::= class-name ( ’,’ class-name )*
>>>
>>> class-name ::= <fully qualified class name>
>>>
>>>
>>> As we discussed back on March 25 ("maven-bundle-plugin generating
>>> Import-Service entries"), the maven bundle plugin is adding a lot of
>>> non-compliant information, e.g.
>>>
>>> Import-Service: org.apache.aries.blueprint.NamespaceHandler;filter="(o
>>>
>>> sgi.service.blueprint.namespace=http://aries.apache.org/xmlns/transac
>>>
>>> tions/v1.0.0)",org.apache.aries.blueprint.NamespaceHandler;filter="(o
>>>
>>> sgi.service.blueprint.namespace=http://aries.apache.org/xmlns/jpa/v1.
>>> 0.0)"
>>>
>>> Regards,
>>> Mark
>>>
>>> On 23 September 2010 14:41, Guillaume Nodet <gn...@gmail.com> wrote:
>>>
>>>> The maven bundle plugin actaully check if the service is mandatory or
>>>> not and should add that into the Import-Service manifest header.
>>>> What exactly is not right with those headers ?
>>>>
>>>> On Thu, Sep 23, 2010 at 12:29, Timothy Ward <ti...@hotmail.com>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> There are some problems with the way in which Aries models bundles for
>>>> resolution in OBR. Currently we look at the blueprint for imported and
>>>> exported services, but also fall back to the Import-Service and
>>>> Export-Service headers in case there are any legacy bundles.
>>>>>
>>>>> Unfortunately it seems as though all of our bundles have Import-Service
>>>> and Export-Service headers generated (using non-standard directives and
>>>> attributes to boot). This means that we duplicate service imports and
>>>> exports in our OBR model, which is a major performance concern, but worse,
>>>> the headers are interpreted differently.
>>>>>
>>>>> ARIES-425 was caused by the fact that the duplicate Import-Service header
>>>> caused an optional blueprint service to also be found as a mandatory
>>>> Import-Service. Where are these non-standard, deprecated headers coming from
>>>> and how can we turn them off?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Tim
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Auto-generation of Import-Service and Export-Service
Posted by Alasdair Nottingham <no...@apache.org>.
That is not the position the alliance takes on deprecated stuff. When they deprecated stuff they don't "cease" to specify it, they just stop putting it in specs. It is still specified as it was in the OSGi R3 spec.
As I said back then if you want to do this you should be using non-standard headers, or get the Alliance to change the spec.
Alasdair Nottingham
On 23 Sep 2010, at 06:59, Guillaume Nodet <gn...@gmail.com> wrote:
> Right, and they are deprecated, so their syntax isn't defined anymore
> in the specs ;-)
> So that's completely untrue to say those headers are non-compliant,
> unless you plan to
> deploy on an OSGi 3 platform, which Aries does not support.
>
> Given those headers are not used by the OSGi framework, I fail to see
> what kind of
> problems it could lead to.
>
> Also, the generation you are referring to (about the namespace
> handlers additional service
> imports) have been removed in all maven modules afaik.
>
> I'd be happy to actually fix anything in the generation as I said. If
> the generated information
> can't be mapped back to the blueprint services, there is actaully a
> problem somewhere,
> else the information generated by the application deployer and the
> maven bundle plugin
> should be the same.
>
> Please remember, Aries components might be consumed by means other than Aries
> applications. Also, Aries applications can contains bundles based on
> tools other than
> Blueprint and the use of those headers is currently the only to have
> this metadata available
> for everyone.
>
>
> On Thu, Sep 23, 2010 at 15:49, Mark Nuttall <mn...@apache.org> wrote:
>> These deprecated headers were defined in the version 3 spec, section 4.14
>>
>>
>> 4.14 Importing and Exporting Services
>> The Export-Service manifest header declares the interfaces that a bundle
>> may register. It provides advisory information that is not used by the
>> Frame-
>> work. This header is intended for use by server-side management tools.
>> The Export-Service manifest header must conform to the following syntax:
>>
>>
>> Export-Service ::= class-name ( ’,’ class-name )*
>>
>> class-name ::= <fully qualified class name>
>>
>>
>> The Import-Service manifest header declares the interfaces the bundle may
>> use. It provides advisory information that is not used by the Framework.
>> This header is also intended for use by server-side management tools.
>> The Import-Service manifest header must conform to the following syntax:
>>
>> Import-Service ::= class-name ( ’,’ class-name )*
>>
>> class-name ::= <fully qualified class name>
>>
>>
>> As we discussed back on March 25 ("maven-bundle-plugin generating
>> Import-Service entries"), the maven bundle plugin is adding a lot of
>> non-compliant information, e.g.
>>
>> Import-Service: org.apache.aries.blueprint.NamespaceHandler;filter="(o
>>
>> sgi.service.blueprint.namespace=http://aries.apache.org/xmlns/transac
>>
>> tions/v1.0.0)",org.apache.aries.blueprint.NamespaceHandler;filter="(o
>>
>> sgi.service.blueprint.namespace=http://aries.apache.org/xmlns/jpa/v1.
>> 0.0)"
>>
>> Regards,
>> Mark
>>
>> On 23 September 2010 14:41, Guillaume Nodet <gn...@gmail.com> wrote:
>>
>>> The maven bundle plugin actaully check if the service is mandatory or
>>> not and should add that into the Import-Service manifest header.
>>> What exactly is not right with those headers ?
>>>
>>> On Thu, Sep 23, 2010 at 12:29, Timothy Ward <ti...@hotmail.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> There are some problems with the way in which Aries models bundles for
>>> resolution in OBR. Currently we look at the blueprint for imported and
>>> exported services, but also fall back to the Import-Service and
>>> Export-Service headers in case there are any legacy bundles.
>>>>
>>>> Unfortunately it seems as though all of our bundles have Import-Service
>>> and Export-Service headers generated (using non-standard directives and
>>> attributes to boot). This means that we duplicate service imports and
>>> exports in our OBR model, which is a major performance concern, but worse,
>>> the headers are interpreted differently.
>>>>
>>>> ARIES-425 was caused by the fact that the duplicate Import-Service header
>>> caused an optional blueprint service to also be found as a mandatory
>>> Import-Service. Where are these non-standard, deprecated headers coming from
>>> and how can we turn them off?
>>>>
>>>> Regards,
>>>>
>>>> Tim
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Auto-generation of Import-Service and Export-Service
Posted by Guillaume Nodet <gn...@gmail.com>.
Right, and they are deprecated, so their syntax isn't defined anymore
in the specs ;-)
So that's completely untrue to say those headers are non-compliant,
unless you plan to
deploy on an OSGi 3 platform, which Aries does not support.
Given those headers are not used by the OSGi framework, I fail to see
what kind of
problems it could lead to.
Also, the generation you are referring to (about the namespace
handlers additional service
imports) have been removed in all maven modules afaik.
I'd be happy to actually fix anything in the generation as I said. If
the generated information
can't be mapped back to the blueprint services, there is actaully a
problem somewhere,
else the information generated by the application deployer and the
maven bundle plugin
should be the same.
Please remember, Aries components might be consumed by means other than Aries
applications. Also, Aries applications can contains bundles based on
tools other than
Blueprint and the use of those headers is currently the only to have
this metadata available
for everyone.
On Thu, Sep 23, 2010 at 15:49, Mark Nuttall <mn...@apache.org> wrote:
> These deprecated headers were defined in the version 3 spec, section 4.14
>
>
> 4.14 Importing and Exporting Services
> The Export-Service manifest header declares the interfaces that a bundle
> may register. It provides advisory information that is not used by the
> Frame-
> work. This header is intended for use by server-side management tools.
> The Export-Service manifest header must conform to the following syntax:
>
>
> Export-Service ::= class-name ( ’,’ class-name )*
>
> class-name ::= <fully qualified class name>
>
>
> The Import-Service manifest header declares the interfaces the bundle may
> use. It provides advisory information that is not used by the Framework.
> This header is also intended for use by server-side management tools.
> The Import-Service manifest header must conform to the following syntax:
>
> Import-Service ::= class-name ( ’,’ class-name )*
>
> class-name ::= <fully qualified class name>
>
>
> As we discussed back on March 25 ("maven-bundle-plugin generating
> Import-Service entries"), the maven bundle plugin is adding a lot of
> non-compliant information, e.g.
>
> Import-Service: org.apache.aries.blueprint.NamespaceHandler;filter="(o
>
> sgi.service.blueprint.namespace=http://aries.apache.org/xmlns/transac
>
> tions/v1.0.0)",org.apache.aries.blueprint.NamespaceHandler;filter="(o
>
> sgi.service.blueprint.namespace=http://aries.apache.org/xmlns/jpa/v1.
> 0.0)"
>
> Regards,
> Mark
>
> On 23 September 2010 14:41, Guillaume Nodet <gn...@gmail.com> wrote:
>
>> The maven bundle plugin actaully check if the service is mandatory or
>> not and should add that into the Import-Service manifest header.
>> What exactly is not right with those headers ?
>>
>> On Thu, Sep 23, 2010 at 12:29, Timothy Ward <ti...@hotmail.com>
>> wrote:
>> >
>> > Hi,
>> >
>> > There are some problems with the way in which Aries models bundles for
>> resolution in OBR. Currently we look at the blueprint for imported and
>> exported services, but also fall back to the Import-Service and
>> Export-Service headers in case there are any legacy bundles.
>> >
>> > Unfortunately it seems as though all of our bundles have Import-Service
>> and Export-Service headers generated (using non-standard directives and
>> attributes to boot). This means that we duplicate service imports and
>> exports in our OBR model, which is a major performance concern, but worse,
>> the headers are interpreted differently.
>> >
>> > ARIES-425 was caused by the fact that the duplicate Import-Service header
>> caused an optional blueprint service to also be found as a mandatory
>> Import-Service. Where are these non-standard, deprecated headers coming from
>> and how can we turn them off?
>> >
>> > Regards,
>> >
>> > Tim
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Auto-generation of Import-Service and Export-Service
Posted by Mark Nuttall <mn...@apache.org>.
These deprecated headers were defined in the version 3 spec, section 4.14
4.14 Importing and Exporting Services
The Export-Service manifest header declares the interfaces that a bundle
may register. It provides advisory information that is not used by the
Frame-
work. This header is intended for use by server-side management tools.
The Export-Service manifest header must conform to the following syntax:
Export-Service ::= class-name ( ’,’ class-name )*
class-name ::= <fully qualified class name>
The Import-Service manifest header declares the interfaces the bundle may
use. It provides advisory information that is not used by the Framework.
This header is also intended for use by server-side management tools.
The Import-Service manifest header must conform to the following syntax:
Import-Service ::= class-name ( ’,’ class-name )*
class-name ::= <fully qualified class name>
As we discussed back on March 25 ("maven-bundle-plugin generating
Import-Service entries"), the maven bundle plugin is adding a lot of
non-compliant information, e.g.
Import-Service: org.apache.aries.blueprint.NamespaceHandler;filter="(o
sgi.service.blueprint.namespace=http://aries.apache.org/xmlns/transac
tions/v1.0.0)",org.apache.aries.blueprint.NamespaceHandler;filter="(o
sgi.service.blueprint.namespace=http://aries.apache.org/xmlns/jpa/v1.
0.0)"
Regards,
Mark
On 23 September 2010 14:41, Guillaume Nodet <gn...@gmail.com> wrote:
> The maven bundle plugin actaully check if the service is mandatory or
> not and should add that into the Import-Service manifest header.
> What exactly is not right with those headers ?
>
> On Thu, Sep 23, 2010 at 12:29, Timothy Ward <ti...@hotmail.com>
> wrote:
> >
> > Hi,
> >
> > There are some problems with the way in which Aries models bundles for
> resolution in OBR. Currently we look at the blueprint for imported and
> exported services, but also fall back to the Import-Service and
> Export-Service headers in case there are any legacy bundles.
> >
> > Unfortunately it seems as though all of our bundles have Import-Service
> and Export-Service headers generated (using non-standard directives and
> attributes to boot). This means that we duplicate service imports and
> exports in our OBR model, which is a major performance concern, but worse,
> the headers are interpreted differently.
> >
> > ARIES-425 was caused by the fact that the duplicate Import-Service header
> caused an optional blueprint service to also be found as a mandatory
> Import-Service. Where are these non-standard, deprecated headers coming from
> and how can we turn them off?
> >
> > Regards,
> >
> > Tim
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Auto-generation of Import-Service and Export-Service
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Sep 23, 2010 at 17:52, Timothy Ward <ti...@hotmail.com> wrote:
>
> Well there was ARIES-425, I had to put in a fix to understand the availability directive.
>
> It's possible that we also incorrectly interpret that directive as an attribute for matching - I don't know that the code was ever written to cope with a more extended syntax than the basic Import-Package. All I've done at the moment is the bare minimum to get things working, which is to read the availability directive to find out if something is optional.
>
> Might anything else ever be used e.g. resolution:="optional" or optional:="true"?
That that I know of.
>
> I would much rather have a separate class implemented where we can clearly state our assumptions about the syntax. It might also be nice to have a source:= directive to indicate where the service came from (e.g. blueprint, DS, etc). That would allow people to filter out services that they find out about from elsewhere.
Those are good ideas, I like those constructive comments a lot.
The code that generates the headers for blueprint are specified lives
at http://svn.apache.org/repos/asf/felix/trunk/bundleplugin/src/main/resources/org/apache/felix/bundleplugin/blueprint.xsl
The source attribute should be easy to add in the xsl, so a simple
patch would do the trick for that one.
>
> Tim
>
>
>
> ----------------------------------------
>> Date: Thu, 23 Sep 2010 17:29:32 +0200
>> Subject: Re: Auto-generation of Import-Service and Export-Service
>> From: gnodet@gmail.com
>> To: aries-dev@incubator.apache.org
>>
>> Which other projects are you talking about?
>> In the last discussion, I had asked if there was actually any *real*
>> problem with redefining those headers other than making an argument
>> about the fact that those are not compliant with OSGi R3 and received
>> no answers. Still the case here. I'm not aware of anything broken so
>> far.
>>
>> On Thu, Sep 23, 2010 at 17:22, Timothy Ward wrote:
>>>
>>> Guillaume,
>>>
>>> I do see why one might want this information in bundle headers, but I'm afraid I don't understand why it needs to re-use the Import-Service and Export-Service headers.
>>>
>>> If it were to use a different header (one not defined by OSGi) it would not cause problems to other projects that are unaware of the custom extensions. Right now the implementation of the bundle plugin requires everyone that ever used the existing Import-Service and Export-Service headers to understand the non-standard behaviour.
>>>
>>> I'm not wild about this metadata being generated for all bundles by default, but I wouldn't mind anywhere near as much if it weren't redefining an existing header and, as a result, breaking other projects.
>>>
>>> Regards,
>>>
>>> Tim
>>>
>>> ----------------------------------------
>>>> Date: Thu, 23 Sep 2010 16:54:52 +0200
>>>> Subject: Re: Auto-generation of Import-Service and Export-Service
>>>> From: gnodet@gmail.com
>>>> To: aries-dev@incubator.apache.org
>>>>
>>>> On Thu, Sep 23, 2010 at 16:05, Timothy Ward wrote:
>>>>>
>>>>> The headers are incorrect because they violate the syntax for Import-Service and Export-Service. From the OSGi 3 specification:
>>>>>
>>>>> -----------------------------------------------------------------------------------------
>>>>>
>>>>> 4.14 Importing and Exporting Services
>>>>>
>>>>> The Export-Service manifest header declares the interfaces that a bundle
>>>>> may register. It provides advisory information that is not used by the Framework.
>>>>> This header is intended for use by server-side management tools.
>>>>>
>>>>> The Export-Service manifest header must conform to the following syntax:
>>>>>
>>>>> Export-Service ::= class-name ( ’,’ class-name )*
>>>>> class-name ::=
>>>>>
>>>>> The Import-Service manifest header declares the interfaces the bundle may
>>>>> use. It provides advisory information that is not used by the Framework.
>>>>> This header is also intended for use by server-side management tools.
>>>>>
>>>>> The Import-Service manifest header must conform to the following syntax:
>>>>>
>>>>> Import-Service ::= class-name ( ’,’ class-name )*
>>>>> class-name ::=
>>>>>
>>>>> ------------------------------------------------------------------------------------------
>>>>>
>>>>> According to the specification it is not valid to supply any attributes or directives, this means that anyone using this header may fail to process any bundle which does. It also means that there's no standard way for anyone to indicate service properties, filters or optionality. The fact that the bundle plugin is doing this is actually causing bugs which we are having to work around.
>>>>
>>>> But since when is Aries supporting OSGi R3 ? We have requirements on
>>>> OSGi R 4.2 afaik.
>>>>
>>>> This syntax specification comes from R3 and the R4 specs does not
>>>> specify the syntax for those headers. I doubled checked a while back
>>>> with osgi experts about that.
>>>> Also if you have any tooling which supports OSGi R3 bundles, I must
>>>> suppose it's a bit buggy because it's easy to check if a bundle is a
>>>> R3 or R4 bundles by verifying if the Bundle-ManifestVersion is 2 or
>>>> not. Those headers should be ignored for all R4 bundles.
>>>>
>>>>> If the bundle plugin needs to implement some custom function to support some special use-cases in Felix then it should be using a custom manifest header, and preferrably it should only add that header when configured to do so. Right now anyone who uses the bundle plugin is, without their knowledge, generating bundles that use an OSGi reserved header with syntax that violates the core spec.
>>>>
>>>> Headers generated can always be removed in the bundle plugin by using
>>>> the -removeheaders command for bnd.
>>>> But I'd rather find another solution as I think this information is of
>>>> real importance, especially in the generated OBR xml file.
>>>>
>>>>
>>>>
>>>>> Regards,
>>>>>
>>>>> Tim
>>>>>
>>>>> ----------------------------------------
>>>>>> Date: Thu, 23 Sep 2010 15:41:11 +0200
>>>>>> Subject: Re: Auto-generation of Import-Service and Export-Service
>>>>>> From: gnodet@gmail.com
>>>>>> To: aries-dev@incubator.apache.org
>>>>>>
>>>>>> The maven bundle plugin actaully check if the service is mandatory or
>>>>>> not and should add that into the Import-Service manifest header.
>>>>>> What exactly is not right with those headers ?
>>>>>>
>>>>>> On Thu, Sep 23, 2010 at 12:29, Timothy Ward wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> There are some problems with the way in which Aries models bundles for resolution in OBR. Currently we look at the blueprint for imported and exported services, but also fall back to the Import-Service and Export-Service headers in case there are any legacy bundles.
>>>>>>>
>>>>>>> Unfortunately it seems as though all of our bundles have Import-Service and Export-Service headers generated (using non-standard directives and attributes to boot). This means that we duplicate service imports and exports in our OBR model, which is a major performance concern, but worse, the headers are interpreted differently.
>>>>>>>
>>>>>>> ARIES-425 was caused by the fact that the duplicate Import-Service header caused an optional blueprint service to also be found as a mandatory Import-Service. Where are these non-standard, deprecated headers coming from and how can we turn them off?
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Tim
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
RE: Auto-generation of Import-Service and Export-Service
Posted by Timothy Ward <ti...@hotmail.com>.
Well there was ARIES-425, I had to put in a fix to understand the availability directive.
It's possible that we also incorrectly interpret that directive as an attribute for matching - I don't know that the code was ever written to cope with a more extended syntax than the basic Import-Package. All I've done at the moment is the bare minimum to get things working, which is to read the availability directive to find out if something is optional.
Might anything else ever be used e.g. resolution:="optional" or optional:="true"?
I would much rather have a separate class implemented where we can clearly state our assumptions about the syntax. It might also be nice to have a source:= directive to indicate where the service came from (e.g. blueprint, DS, etc). That would allow people to filter out services that they find out about from elsewhere.
Tim
----------------------------------------
> Date: Thu, 23 Sep 2010 17:29:32 +0200
> Subject: Re: Auto-generation of Import-Service and Export-Service
> From: gnodet@gmail.com
> To: aries-dev@incubator.apache.org
>
> Which other projects are you talking about?
> In the last discussion, I had asked if there was actually any *real*
> problem with redefining those headers other than making an argument
> about the fact that those are not compliant with OSGi R3 and received
> no answers. Still the case here. I'm not aware of anything broken so
> far.
>
> On Thu, Sep 23, 2010 at 17:22, Timothy Ward wrote:
>>
>> Guillaume,
>>
>> I do see why one might want this information in bundle headers, but I'm afraid I don't understand why it needs to re-use the Import-Service and Export-Service headers.
>>
>> If it were to use a different header (one not defined by OSGi) it would not cause problems to other projects that are unaware of the custom extensions. Right now the implementation of the bundle plugin requires everyone that ever used the existing Import-Service and Export-Service headers to understand the non-standard behaviour.
>>
>> I'm not wild about this metadata being generated for all bundles by default, but I wouldn't mind anywhere near as much if it weren't redefining an existing header and, as a result, breaking other projects.
>>
>> Regards,
>>
>> Tim
>>
>> ----------------------------------------
>>> Date: Thu, 23 Sep 2010 16:54:52 +0200
>>> Subject: Re: Auto-generation of Import-Service and Export-Service
>>> From: gnodet@gmail.com
>>> To: aries-dev@incubator.apache.org
>>>
>>> On Thu, Sep 23, 2010 at 16:05, Timothy Ward wrote:
>>>>
>>>> The headers are incorrect because they violate the syntax for Import-Service and Export-Service. From the OSGi 3 specification:
>>>>
>>>> -----------------------------------------------------------------------------------------
>>>>
>>>> 4.14 Importing and Exporting Services
>>>>
>>>> The Export-Service manifest header declares the interfaces that a bundle
>>>> may register. It provides advisory information that is not used by the Framework.
>>>> This header is intended for use by server-side management tools.
>>>>
>>>> The Export-Service manifest header must conform to the following syntax:
>>>>
>>>> Export-Service ::= class-name ( ’,’ class-name )*
>>>> class-name ::=
>>>>
>>>> The Import-Service manifest header declares the interfaces the bundle may
>>>> use. It provides advisory information that is not used by the Framework.
>>>> This header is also intended for use by server-side management tools.
>>>>
>>>> The Import-Service manifest header must conform to the following syntax:
>>>>
>>>> Import-Service ::= class-name ( ’,’ class-name )*
>>>> class-name ::=
>>>>
>>>> ------------------------------------------------------------------------------------------
>>>>
>>>> According to the specification it is not valid to supply any attributes or directives, this means that anyone using this header may fail to process any bundle which does. It also means that there's no standard way for anyone to indicate service properties, filters or optionality. The fact that the bundle plugin is doing this is actually causing bugs which we are having to work around.
>>>
>>> But since when is Aries supporting OSGi R3 ? We have requirements on
>>> OSGi R 4.2 afaik.
>>>
>>> This syntax specification comes from R3 and the R4 specs does not
>>> specify the syntax for those headers. I doubled checked a while back
>>> with osgi experts about that.
>>> Also if you have any tooling which supports OSGi R3 bundles, I must
>>> suppose it's a bit buggy because it's easy to check if a bundle is a
>>> R3 or R4 bundles by verifying if the Bundle-ManifestVersion is 2 or
>>> not. Those headers should be ignored for all R4 bundles.
>>>
>>>> If the bundle plugin needs to implement some custom function to support some special use-cases in Felix then it should be using a custom manifest header, and preferrably it should only add that header when configured to do so. Right now anyone who uses the bundle plugin is, without their knowledge, generating bundles that use an OSGi reserved header with syntax that violates the core spec.
>>>
>>> Headers generated can always be removed in the bundle plugin by using
>>> the -removeheaders command for bnd.
>>> But I'd rather find another solution as I think this information is of
>>> real importance, especially in the generated OBR xml file.
>>>
>>>
>>>
>>>> Regards,
>>>>
>>>> Tim
>>>>
>>>> ----------------------------------------
>>>>> Date: Thu, 23 Sep 2010 15:41:11 +0200
>>>>> Subject: Re: Auto-generation of Import-Service and Export-Service
>>>>> From: gnodet@gmail.com
>>>>> To: aries-dev@incubator.apache.org
>>>>>
>>>>> The maven bundle plugin actaully check if the service is mandatory or
>>>>> not and should add that into the Import-Service manifest header.
>>>>> What exactly is not right with those headers ?
>>>>>
>>>>> On Thu, Sep 23, 2010 at 12:29, Timothy Ward wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> There are some problems with the way in which Aries models bundles for resolution in OBR. Currently we look at the blueprint for imported and exported services, but also fall back to the Import-Service and Export-Service headers in case there are any legacy bundles.
>>>>>>
>>>>>> Unfortunately it seems as though all of our bundles have Import-Service and Export-Service headers generated (using non-standard directives and attributes to boot). This means that we duplicate service imports and exports in our OBR model, which is a major performance concern, but worse, the headers are interpreted differently.
>>>>>>
>>>>>> ARIES-425 was caused by the fact that the duplicate Import-Service header caused an optional blueprint service to also be found as a mandatory Import-Service. Where are these non-standard, deprecated headers coming from and how can we turn them off?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Auto-generation of Import-Service and Export-Service
Posted by Guillaume Nodet <gn...@gmail.com>.
Which other projects are you talking about?
In the last discussion, I had asked if there was actually any *real*
problem with redefining those headers other than making an argument
about the fact that those are not compliant with OSGi R3 and received
no answers. Still the case here. I'm not aware of anything broken so
far.
On Thu, Sep 23, 2010 at 17:22, Timothy Ward <ti...@hotmail.com> wrote:
>
> Guillaume,
>
> I do see why one might want this information in bundle headers, but I'm afraid I don't understand why it needs to re-use the Import-Service and Export-Service headers.
>
> If it were to use a different header (one not defined by OSGi) it would not cause problems to other projects that are unaware of the custom extensions. Right now the implementation of the bundle plugin requires everyone that ever used the existing Import-Service and Export-Service headers to understand the non-standard behaviour.
>
> I'm not wild about this metadata being generated for all bundles by default, but I wouldn't mind anywhere near as much if it weren't redefining an existing header and, as a result, breaking other projects.
>
> Regards,
>
> Tim
>
> ----------------------------------------
>> Date: Thu, 23 Sep 2010 16:54:52 +0200
>> Subject: Re: Auto-generation of Import-Service and Export-Service
>> From: gnodet@gmail.com
>> To: aries-dev@incubator.apache.org
>>
>> On Thu, Sep 23, 2010 at 16:05, Timothy Ward wrote:
>>>
>>> The headers are incorrect because they violate the syntax for Import-Service and Export-Service. From the OSGi 3 specification:
>>>
>>> -----------------------------------------------------------------------------------------
>>>
>>> 4.14 Importing and Exporting Services
>>>
>>> The Export-Service manifest header declares the interfaces that a bundle
>>> may register. It provides advisory information that is not used by the Framework.
>>> This header is intended for use by server-side management tools.
>>>
>>> The Export-Service manifest header must conform to the following syntax:
>>>
>>> Export-Service ::= class-name ( ’,’ class-name )*
>>> class-name ::=
>>>
>>> The Import-Service manifest header declares the interfaces the bundle may
>>> use. It provides advisory information that is not used by the Framework.
>>> This header is also intended for use by server-side management tools.
>>>
>>> The Import-Service manifest header must conform to the following syntax:
>>>
>>> Import-Service ::= class-name ( ’,’ class-name )*
>>> class-name ::=
>>>
>>> ------------------------------------------------------------------------------------------
>>>
>>> According to the specification it is not valid to supply any attributes or directives, this means that anyone using this header may fail to process any bundle which does. It also means that there's no standard way for anyone to indicate service properties, filters or optionality. The fact that the bundle plugin is doing this is actually causing bugs which we are having to work around.
>>
>> But since when is Aries supporting OSGi R3 ? We have requirements on
>> OSGi R 4.2 afaik.
>>
>> This syntax specification comes from R3 and the R4 specs does not
>> specify the syntax for those headers. I doubled checked a while back
>> with osgi experts about that.
>> Also if you have any tooling which supports OSGi R3 bundles, I must
>> suppose it's a bit buggy because it's easy to check if a bundle is a
>> R3 or R4 bundles by verifying if the Bundle-ManifestVersion is 2 or
>> not. Those headers should be ignored for all R4 bundles.
>>
>>> If the bundle plugin needs to implement some custom function to support some special use-cases in Felix then it should be using a custom manifest header, and preferrably it should only add that header when configured to do so. Right now anyone who uses the bundle plugin is, without their knowledge, generating bundles that use an OSGi reserved header with syntax that violates the core spec.
>>
>> Headers generated can always be removed in the bundle plugin by using
>> the -removeheaders command for bnd.
>> But I'd rather find another solution as I think this information is of
>> real importance, especially in the generated OBR xml file.
>>
>>
>>
>>> Regards,
>>>
>>> Tim
>>>
>>> ----------------------------------------
>>>> Date: Thu, 23 Sep 2010 15:41:11 +0200
>>>> Subject: Re: Auto-generation of Import-Service and Export-Service
>>>> From: gnodet@gmail.com
>>>> To: aries-dev@incubator.apache.org
>>>>
>>>> The maven bundle plugin actaully check if the service is mandatory or
>>>> not and should add that into the Import-Service manifest header.
>>>> What exactly is not right with those headers ?
>>>>
>>>> On Thu, Sep 23, 2010 at 12:29, Timothy Ward wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> There are some problems with the way in which Aries models bundles for resolution in OBR. Currently we look at the blueprint for imported and exported services, but also fall back to the Import-Service and Export-Service headers in case there are any legacy bundles.
>>>>>
>>>>> Unfortunately it seems as though all of our bundles have Import-Service and Export-Service headers generated (using non-standard directives and attributes to boot). This means that we duplicate service imports and exports in our OBR model, which is a major performance concern, but worse, the headers are interpreted differently.
>>>>>
>>>>> ARIES-425 was caused by the fact that the duplicate Import-Service header caused an optional blueprint service to also be found as a mandatory Import-Service. Where are these non-standard, deprecated headers coming from and how can we turn them off?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Tim
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
RE: Auto-generation of Import-Service and Export-Service
Posted by Timothy Ward <ti...@hotmail.com>.
Guillaume,
I do see why one might want this information in bundle headers, but I'm afraid I don't understand why it needs to re-use the Import-Service and Export-Service headers.
If it were to use a different header (one not defined by OSGi) it would not cause problems to other projects that are unaware of the custom extensions. Right now the implementation of the bundle plugin requires everyone that ever used the existing Import-Service and Export-Service headers to understand the non-standard behaviour.
I'm not wild about this metadata being generated for all bundles by default, but I wouldn't mind anywhere near as much if it weren't redefining an existing header and, as a result, breaking other projects.
Regards,
Tim
----------------------------------------
> Date: Thu, 23 Sep 2010 16:54:52 +0200
> Subject: Re: Auto-generation of Import-Service and Export-Service
> From: gnodet@gmail.com
> To: aries-dev@incubator.apache.org
>
> On Thu, Sep 23, 2010 at 16:05, Timothy Ward wrote:
>>
>> The headers are incorrect because they violate the syntax for Import-Service and Export-Service. From the OSGi 3 specification:
>>
>> -----------------------------------------------------------------------------------------
>>
>> 4.14 Importing and Exporting Services
>>
>> The Export-Service manifest header declares the interfaces that a bundle
>> may register. It provides advisory information that is not used by the Framework.
>> This header is intended for use by server-side management tools.
>>
>> The Export-Service manifest header must conform to the following syntax:
>>
>> Export-Service ::= class-name ( ’,’ class-name )*
>> class-name ::=
>>
>> The Import-Service manifest header declares the interfaces the bundle may
>> use. It provides advisory information that is not used by the Framework.
>> This header is also intended for use by server-side management tools.
>>
>> The Import-Service manifest header must conform to the following syntax:
>>
>> Import-Service ::= class-name ( ’,’ class-name )*
>> class-name ::=
>>
>> ------------------------------------------------------------------------------------------
>>
>> According to the specification it is not valid to supply any attributes or directives, this means that anyone using this header may fail to process any bundle which does. It also means that there's no standard way for anyone to indicate service properties, filters or optionality. The fact that the bundle plugin is doing this is actually causing bugs which we are having to work around.
>
> But since when is Aries supporting OSGi R3 ? We have requirements on
> OSGi R 4.2 afaik.
>
> This syntax specification comes from R3 and the R4 specs does not
> specify the syntax for those headers. I doubled checked a while back
> with osgi experts about that.
> Also if you have any tooling which supports OSGi R3 bundles, I must
> suppose it's a bit buggy because it's easy to check if a bundle is a
> R3 or R4 bundles by verifying if the Bundle-ManifestVersion is 2 or
> not. Those headers should be ignored for all R4 bundles.
>
>> If the bundle plugin needs to implement some custom function to support some special use-cases in Felix then it should be using a custom manifest header, and preferrably it should only add that header when configured to do so. Right now anyone who uses the bundle plugin is, without their knowledge, generating bundles that use an OSGi reserved header with syntax that violates the core spec.
>
> Headers generated can always be removed in the bundle plugin by using
> the -removeheaders command for bnd.
> But I'd rather find another solution as I think this information is of
> real importance, especially in the generated OBR xml file.
>
>
>
>> Regards,
>>
>> Tim
>>
>> ----------------------------------------
>>> Date: Thu, 23 Sep 2010 15:41:11 +0200
>>> Subject: Re: Auto-generation of Import-Service and Export-Service
>>> From: gnodet@gmail.com
>>> To: aries-dev@incubator.apache.org
>>>
>>> The maven bundle plugin actaully check if the service is mandatory or
>>> not and should add that into the Import-Service manifest header.
>>> What exactly is not right with those headers ?
>>>
>>> On Thu, Sep 23, 2010 at 12:29, Timothy Ward wrote:
>>>>
>>>> Hi,
>>>>
>>>> There are some problems with the way in which Aries models bundles for resolution in OBR. Currently we look at the blueprint for imported and exported services, but also fall back to the Import-Service and Export-Service headers in case there are any legacy bundles.
>>>>
>>>> Unfortunately it seems as though all of our bundles have Import-Service and Export-Service headers generated (using non-standard directives and attributes to boot). This means that we duplicate service imports and exports in our OBR model, which is a major performance concern, but worse, the headers are interpreted differently.
>>>>
>>>> ARIES-425 was caused by the fact that the duplicate Import-Service header caused an optional blueprint service to also be found as a mandatory Import-Service. Where are these non-standard, deprecated headers coming from and how can we turn them off?
>>>>
>>>> Regards,
>>>>
>>>> Tim
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Auto-generation of Import-Service and Export-Service
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Sep 23, 2010 at 16:05, Timothy Ward <ti...@hotmail.com> wrote:
>
> The headers are incorrect because they violate the syntax for Import-Service and Export-Service. From the OSGi 3 specification:
>
> -----------------------------------------------------------------------------------------
>
> 4.14 Importing and Exporting Services
>
> The Export-Service manifest header declares the interfaces that a bundle
> may register. It provides advisory information that is not used by the Framework.
> This header is intended for use by server-side management tools.
>
> The Export-Service manifest header must conform to the following syntax:
>
> Export-Service ::= class-name ( ’,’ class-name )*
> class-name ::= <fully qualified class name>
>
> The Import-Service manifest header declares the interfaces the bundle may
> use. It provides advisory information that is not used by the Framework.
> This header is also intended for use by server-side management tools.
>
> The Import-Service manifest header must conform to the following syntax:
>
> Import-Service ::= class-name ( ’,’ class-name )*
> class-name ::= <fully qualified class name>
>
> ------------------------------------------------------------------------------------------
>
> According to the specification it is not valid to supply any attributes or directives, this means that anyone using this header may fail to process any bundle which does. It also means that there's no standard way for anyone to indicate service properties, filters or optionality. The fact that the bundle plugin is doing this is actually causing bugs which we are having to work around.
But since when is Aries supporting OSGi R3 ? We have requirements on
OSGi R 4.2 afaik.
This syntax specification comes from R3 and the R4 specs does not
specify the syntax for those headers. I doubled checked a while back
with osgi experts about that.
Also if you have any tooling which supports OSGi R3 bundles, I must
suppose it's a bit buggy because it's easy to check if a bundle is a
R3 or R4 bundles by verifying if the Bundle-ManifestVersion is 2 or
not. Those headers should be ignored for all R4 bundles.
> If the bundle plugin needs to implement some custom function to support some special use-cases in Felix then it should be using a custom manifest header, and preferrably it should only add that header when configured to do so. Right now anyone who uses the bundle plugin is, without their knowledge, generating bundles that use an OSGi reserved header with syntax that violates the core spec.
Headers generated can always be removed in the bundle plugin by using
the -removeheaders command for bnd.
But I'd rather find another solution as I think this information is of
real importance, especially in the generated OBR xml file.
> Regards,
>
> Tim
>
> ----------------------------------------
>> Date: Thu, 23 Sep 2010 15:41:11 +0200
>> Subject: Re: Auto-generation of Import-Service and Export-Service
>> From: gnodet@gmail.com
>> To: aries-dev@incubator.apache.org
>>
>> The maven bundle plugin actaully check if the service is mandatory or
>> not and should add that into the Import-Service manifest header.
>> What exactly is not right with those headers ?
>>
>> On Thu, Sep 23, 2010 at 12:29, Timothy Ward wrote:
>>>
>>> Hi,
>>>
>>> There are some problems with the way in which Aries models bundles for resolution in OBR. Currently we look at the blueprint for imported and exported services, but also fall back to the Import-Service and Export-Service headers in case there are any legacy bundles.
>>>
>>> Unfortunately it seems as though all of our bundles have Import-Service and Export-Service headers generated (using non-standard directives and attributes to boot). This means that we duplicate service imports and exports in our OBR model, which is a major performance concern, but worse, the headers are interpreted differently.
>>>
>>> ARIES-425 was caused by the fact that the duplicate Import-Service header caused an optional blueprint service to also be found as a mandatory Import-Service. Where are these non-standard, deprecated headers coming from and how can we turn them off?
>>>
>>> Regards,
>>>
>>> Tim
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
RE: Auto-generation of Import-Service and Export-Service
Posted by Timothy Ward <ti...@hotmail.com>.
The headers are incorrect because they violate the syntax for Import-Service and Export-Service. From the OSGi 3 specification:
-----------------------------------------------------------------------------------------
4.14 Importing and Exporting Services
The Export-Service manifest header declares the interfaces that a bundle
may register. It provides advisory information that is not used by the Framework.
This header is intended for use by server-side management tools.
The Export-Service manifest header must conform to the following syntax:
Export-Service ::= class-name ( ’,’ class-name )*
class-name ::= <fully qualified class name>
The Import-Service manifest header declares the interfaces the bundle may
use. It provides advisory information that is not used by the Framework.
This header is also intended for use by server-side management tools.
The Import-Service manifest header must conform to the following syntax:
Import-Service ::= class-name ( ’,’ class-name )*
class-name ::= <fully qualified class name>
------------------------------------------------------------------------------------------
According to the specification it is not valid to supply any attributes or directives, this means that anyone using this header may fail to process any bundle which does. It also means that there's no standard way for anyone to indicate service properties, filters or optionality. The fact that the bundle plugin is doing this is actually causing bugs which we are having to work around.
If the bundle plugin needs to implement some custom function to support some special use-cases in Felix then it should be using a custom manifest header, and preferrably it should only add that header when configured to do so. Right now anyone who uses the bundle plugin is, without their knowledge, generating bundles that use an OSGi reserved header with syntax that violates the core spec.
Regards,
Tim
----------------------------------------
> Date: Thu, 23 Sep 2010 15:41:11 +0200
> Subject: Re: Auto-generation of Import-Service and Export-Service
> From: gnodet@gmail.com
> To: aries-dev@incubator.apache.org
>
> The maven bundle plugin actaully check if the service is mandatory or
> not and should add that into the Import-Service manifest header.
> What exactly is not right with those headers ?
>
> On Thu, Sep 23, 2010 at 12:29, Timothy Ward wrote:
>>
>> Hi,
>>
>> There are some problems with the way in which Aries models bundles for resolution in OBR. Currently we look at the blueprint for imported and exported services, but also fall back to the Import-Service and Export-Service headers in case there are any legacy bundles.
>>
>> Unfortunately it seems as though all of our bundles have Import-Service and Export-Service headers generated (using non-standard directives and attributes to boot). This means that we duplicate service imports and exports in our OBR model, which is a major performance concern, but worse, the headers are interpreted differently.
>>
>> ARIES-425 was caused by the fact that the duplicate Import-Service header caused an optional blueprint service to also be found as a mandatory Import-Service. Where are these non-standard, deprecated headers coming from and how can we turn them off?
>>
>> Regards,
>>
>> Tim
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Auto-generation of Import-Service and Export-Service
Posted by Guillaume Nodet <gn...@gmail.com>.
The maven bundle plugin actaully check if the service is mandatory or
not and should add that into the Import-Service manifest header.
What exactly is not right with those headers ?
On Thu, Sep 23, 2010 at 12:29, Timothy Ward <ti...@hotmail.com> wrote:
>
> Hi,
>
> There are some problems with the way in which Aries models bundles for resolution in OBR. Currently we look at the blueprint for imported and exported services, but also fall back to the Import-Service and Export-Service headers in case there are any legacy bundles.
>
> Unfortunately it seems as though all of our bundles have Import-Service and Export-Service headers generated (using non-standard directives and attributes to boot). This means that we duplicate service imports and exports in our OBR model, which is a major performance concern, but worse, the headers are interpreted differently.
>
> ARIES-425 was caused by the fact that the duplicate Import-Service header caused an optional blueprint service to also be found as a mandatory Import-Service. Where are these non-standard, deprecated headers coming from and how can we turn them off?
>
> Regards,
>
> Tim
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com