Re: [osgi-dev] Questions about JAX-RS Extension services

2017-08-25 Thread Raymond Auge
The spec states ".. static extensions being ranked below all whiteboard
services".

- Ray

On Fri, Aug 25, 2017 at 9:51 AM, Bram Pouwelse  wrote:

> I think the service ranking trick could work but .. what about an
> application that has a custom one defined in the application itself?
>
> On Fri, Aug 25, 2017 at 3:46 PM Tim Ward  wrote:
>
>> In that case register the custom one targeting that exact application,
>> and give it a higher service ranking than the default writer.
>>
>> Tim
>>
>> Sent from my iPhone
>>
>> On 25 Aug 2017, at 14:26, Bram Pouwelse  wrote:
>>
>> I was more woried about  conflicts, for example a default "*MessageBodyWriter
>> to provide JSON serialization*" I could register that targeting all
>> applications but some application could need a customized one?
>>
>> Bram
>>
>> On Fri, Aug 25, 2017 at 3:20 PM Raymond Auge 
>> wrote:
>>
>>> Binding an extension to every app is pretty much free since only those
>>> resources/applications/extensions having a dependency on it can/will
>>> use it! Right?
>>>
>>> - Ray
>>>
>>> On Thu, Aug 24, 2017 at 3:34 PM, Bram Pouwelse 
>>> wrote:
>>>
 I was mainly looking for the possibility to register extensions
 available for multiple applications to use but not bind them to all. The
 extend.me example in Tim's answer didn't cross my mind but I guess
 that should do the trick :)

 Thanks guys!

 On Wed, Aug 23, 2017 at 11:12 AM Timothy Ward 
 wrote:

> Hi Bram,
>
> It sounds like you have something of an advanced use case in that you
> want to selectively provide a whiteboard extension (which is achieved 
> using
> the application select property) and you want to prevent certain
> applications from being deployed until a suitable extension is available
> (which is achieved using the extension select property).
>
> The way I would do this is as follows:
>
>
>- All applications that need the extension must express their
>dependency using the *osgi.jaxrs.extension.select* filter to
>prevent them being picked up by the whiteboard too early. For example 
> by
>using the filter “(osgi.jaxrs.name=myWhiteboardExtension)”
>- The applications that need the extension must also provide a
>property for the extension service to recognise so that it can target 
> them
>using the *osgi.jaxrs.application.select* filter, for example 
> *extend.me
>=true*
>- The extension service must then target only these applications
>using the *osgi.jaxrs.application.select* filter “(extend.me=true)”
>
>
> This sets up the bi-directional targeting that you’re after, while
> also guaranteeing that there are no start-up ordering issues. It is a
> pretty odd situation though.
>
> More typically a whiteboard extension would just be applied to all of
> the applications in the whiteboard, or just target specific applications.
> You would then place extension requirements on specific whiteboard
> resources that need the extension, not blocking the whole application. 
> This
> is doubly true because whiteboard applications should normally contain
> their mandatory extensions as part of the application, not as whiteboard
> additions.
>
> Anyway, I hope this helps to clear things up!
>
> Tim
>
>
> On 22 Aug 2017, at 18:34, Bram Pouwelse  wrote:
>
>
>
> On Tue, Aug 22, 2017 at 4:05 PM Raymond Auge 
> wrote:
>
>> On Tue, Aug 22, 2017 at 8:50 AM, Bram Pouwelse  w
>> rote:
>>
>>> Hi all,
>>>
>>> I have some questions about the "Additional JAX-RS types" section of
>>> the JAX-RS-Services RFC (rfc-217).
>>>
>>> 5.2 Additional JAX-RS types:
>>> …​
>>> *"Extensions should provide an osgi.jaxrs.application.select
>>> property with a filter that will match application to which this 
>>> extensions
>>> will be registered. If no such filter is provided the extension will 
>>> affect
>>> the default application." *
>>> …​
>>>
>>>
>>> 5.2.5 Depending on Extension Services:
>>>
>>>
>>> *"When writing and configuring a JAX-RS resource or extension it is
>>> possible for one extension to depend on another. For example a JAX-RS
>>> resource may have a dependency upon a MessageBodyWriter to provide JSON
>>> serialization, or a ContainerRequestFilter may depend on a 
>>> ContextResolver
>>> to provide injected configuration.*
>>>
>>>
>>> *In these cases it is necessary to express a dependency on the
>>> existence of an extension within the JAX-RS container. This can be
>>> expressed on any 

Re: [osgi-dev] Questions about JAX-RS Extension services

2017-08-25 Thread Bram Pouwelse
I think the service ranking trick could work but .. what about an
application that has a custom one defined in the application itself?

On Fri, Aug 25, 2017 at 3:46 PM Tim Ward  wrote:

> In that case register the custom one targeting that exact application, and
> give it a higher service ranking than the default writer.
>
> Tim
>
> Sent from my iPhone
>
> On 25 Aug 2017, at 14:26, Bram Pouwelse  wrote:
>
> I was more woried about  conflicts, for example a default "*MessageBodyWriter
> to provide JSON serialization*" I could register that targeting all
> applications but some application could need a customized one?
>
> Bram
>
> On Fri, Aug 25, 2017 at 3:20 PM Raymond Auge 
> wrote:
>
>> Binding an extension to every app is pretty much free since only those
>> resources/applications/extensions having a dependency on it can/will use
>> it! Right?
>>
>> - Ray
>>
>> On Thu, Aug 24, 2017 at 3:34 PM, Bram Pouwelse  wrote:
>>
>>> I was mainly looking for the possibility to register extensions
>>> available for multiple applications to use but not bind them to all. The
>>> extend.me example in Tim's answer didn't cross my mind but I guess that
>>> should do the trick :)
>>>
>>> Thanks guys!
>>>
>>> On Wed, Aug 23, 2017 at 11:12 AM Timothy Ward 
>>> wrote:
>>>
 Hi Bram,

 It sounds like you have something of an advanced use case in that you
 want to selectively provide a whiteboard extension (which is achieved using
 the application select property) and you want to prevent certain
 applications from being deployed until a suitable extension is available
 (which is achieved using the extension select property).

 The way I would do this is as follows:


- All applications that need the extension must express their
dependency using the *osgi.jaxrs.extension.select* filter to
prevent them being picked up by the whiteboard too early. For example by
using the filter “(osgi.jaxrs.name=myWhiteboardExtension)”
- The applications that need the extension must also provide a
property for the extension service to recognise so that it can target 
 them
using the *osgi.jaxrs.application.select* filter, for example *extend.me
=true*
- The extension service must then target only these applications
using the *osgi.jaxrs.application.select* filter “(extend.me=true)”


 This sets up the bi-directional targeting that you’re after, while also
 guaranteeing that there are no start-up ordering issues. It is a pretty odd
 situation though.

 More typically a whiteboard extension would just be applied to all of
 the applications in the whiteboard, or just target specific applications.
 You would then place extension requirements on specific whiteboard
 resources that need the extension, not blocking the whole application. This
 is doubly true because whiteboard applications should normally contain
 their mandatory extensions as part of the application, not as whiteboard
 additions.

 Anyway, I hope this helps to clear things up!

 Tim


 On 22 Aug 2017, at 18:34, Bram Pouwelse  wrote:



 On Tue, Aug 22, 2017 at 4:05 PM Raymond Auge 
 wrote:

> On Tue, Aug 22, 2017 at 8:50 AM, Bram Pouwelse 
> wrote:
>
>> Hi all,
>>
>> I have some questions about the "Additional JAX-RS types" section of
>> the JAX-RS-Services RFC (rfc-217).
>>
>> 5.2 Additional JAX-RS types:
>> …​
>> *"Extensions should provide an osgi.jaxrs.application.select property
>> with a filter that will match application to which this extensions will 
>> be
>> registered. If no such filter is provided the extension will affect the
>> default application." *
>> …​
>>
>>
>> 5.2.5 Depending on Extension Services:
>>
>>
>> *"When writing and configuring a JAX-RS resource or extension it is
>> possible for one extension to depend on another. For example a JAX-RS
>> resource may have a dependency upon a MessageBodyWriter to provide JSON
>> serialization, or a ContainerRequestFilter may depend on a 
>> ContextResolver
>> to provide injected configuration.*
>>
>>
>> *In these cases it is necessary to express a dependency on the
>> existence of an extension within the JAX-RS container. This can be
>> expressed on any JAX-RS whiteboard service using the
>> osgi.jaxrs.extension.select property. This property has type String+ and
>> contains a list of LDAP filters. These filters will be run against the
>> service properties of each extension service registered with the 
>> container.
>> If all of the supplied filters pass then the 

Re: [osgi-dev] Questions about JAX-RS Extension services

2017-08-25 Thread Tim Ward
In that case register the custom one targeting that exact application, and give 
it a higher service ranking than the default writer. 

Tim

Sent from my iPhone

> On 25 Aug 2017, at 14:26, Bram Pouwelse  wrote:
> 
> I was more woried about  conflicts, for example a default "MessageBodyWriter 
> to provide JSON serialization" I could register that targeting all 
> applications but some application could need a customized one? 
> 
> Bram
> 
>> On Fri, Aug 25, 2017 at 3:20 PM Raymond Auge  
>> wrote:
>> Binding an extension to every app is pretty much free since only those 
>> resources/applications/extensions having a dependency on it can/will use it! 
>> Right?
>> 
>> - Ray
>> 
>>> On Thu, Aug 24, 2017 at 3:34 PM, Bram Pouwelse  wrote:
>>> I was mainly looking for the possibility to register extensions available 
>>> for multiple applications to use but not bind them to all. The extend.me 
>>> example in Tim's answer didn't cross my mind but I guess that should do the 
>>> trick :) 
>>> 
>>> Thanks guys!
>>> 
 On Wed, Aug 23, 2017 at 11:12 AM Timothy Ward  wrote:
 Hi Bram,
 
 It sounds like you have something of an advanced use case in that you want 
 to selectively provide a whiteboard extension (which is achieved using the 
 application select property) and you want to prevent certain applications 
 from being deployed until a suitable extension is available (which is 
 achieved using the extension select property).
 
 The way I would do this is as follows:
 
 All applications that need the extension must express their dependency 
 using the osgi.jaxrs.extension.select filter to prevent them being picked 
 up by the whiteboard too early. For example by using the filter 
 “(osgi.jaxrs.name=myWhiteboardExtension)”
 The applications that need the extension must also provide a property for 
 the extension service to recognise so that it can target them using the 
 osgi.jaxrs.application.select filter, for example extend.me=true
 The extension service must then target only these applications using the 
 osgi.jaxrs.application.select filter “(extend.me=true)”
 
 This sets up the bi-directional targeting that you’re after, while also 
 guaranteeing that there are no start-up ordering issues. It is a pretty 
 odd situation though. 
 
 More typically a whiteboard extension would just be applied to all of the 
 applications in the whiteboard, or just target specific applications. You 
 would then place extension requirements on specific whiteboard resources 
 that need the extension, not blocking the whole application. This is 
 doubly true because whiteboard applications should normally contain their 
 mandatory extensions as part of the application, not as whiteboard 
 additions.
 
 Anyway, I hope this helps to clear things up!
 
 Tim
 
 
> On 22 Aug 2017, at 18:34, Bram Pouwelse  wrote:
> 
> 
> 
> On Tue, Aug 22, 2017 at 4:05 PM Raymond Auge  
> wrote:
>>> On Tue, Aug 22, 2017 at 8:50 AM, Bram Pouwelse  
>>> wrote:
>>> Hi all,
>>> 
>>> I have some questions about the "Additional JAX-RS types" section of 
>>> the JAX-RS-Services RFC (rfc-217).
>>> 
>>> 5.2 Additional JAX-RS types: 
>>> …​
>>> "Extensions should provide an osgi.jaxrs.application.select property 
>>> with a filter that will match application to which this extensions will 
>>> be registered. If no such filter is provided the extension will affect 
>>> the default application." 
>>> …​
>>> 
>>> 
>>> 5.2.5 Depending on Extension Services:
>>> "When writing and configuring a JAX-RS resource or extension it is 
>>> possible for one extension to depend on another. For example a JAX-RS 
>>> resource may have a dependency upon a MessageBodyWriter to provide JSON 
>>> serialization, or a ContainerRequestFilter may depend on a 
>>> ContextResolver to provide injected configuration.
>>> 
>>> In these cases it is necessary to express a dependency on the existence 
>>> of an extension within the JAX-RS container. This can be expressed on 
>>> any JAX-RS whiteboard service using the osgi.jaxrs.extension.select 
>>> property. This property has type String+ and contains a list of LDAP 
>>> filters. These filters will be run against the service properties of 
>>> each extension service registered with the container. If all of the 
>>> supplied filters pass then the whiteboard service will registered. This 
>>> extension checking should be done per Application.
>>> 
>>> If at some point later a necessary extension service dependency becomes 
>>> unavailable then the whiteboard service will become ineligible for 

Re: [osgi-dev] Questions about JAX-RS Extension services

2017-08-25 Thread Raymond Auge
Simply publish your "shared" extension with a low service ranking!

Finally, if an application needs a specific one, they need to depend on it
anyway!

- Ray

On Fri, Aug 25, 2017 at 9:26 AM, Bram Pouwelse  wrote:

> I was more woried about  conflicts, for example a default "*MessageBodyWriter
> to provide JSON serialization*" I could register that targeting all
> applications but some application could need a customized one?
>
> Bram
>
> On Fri, Aug 25, 2017 at 3:20 PM Raymond Auge 
> wrote:
>
>> Binding an extension to every app is pretty much free since only those
>> resources/applications/extensions having a dependency on it can/will use
>> it! Right?
>>
>> - Ray
>>
>> On Thu, Aug 24, 2017 at 3:34 PM, Bram Pouwelse  wrote:
>>
>>> I was mainly looking for the possibility to register extensions
>>> available for multiple applications to use but not bind them to all. The
>>> extend.me example in Tim's answer didn't cross my mind but I guess that
>>> should do the trick :)
>>>
>>> Thanks guys!
>>>
>>> On Wed, Aug 23, 2017 at 11:12 AM Timothy Ward 
>>> wrote:
>>>
 Hi Bram,

 It sounds like you have something of an advanced use case in that you
 want to selectively provide a whiteboard extension (which is achieved using
 the application select property) and you want to prevent certain
 applications from being deployed until a suitable extension is available
 (which is achieved using the extension select property).

 The way I would do this is as follows:


- All applications that need the extension must express their
dependency using the *osgi.jaxrs.extension.select* filter to
prevent them being picked up by the whiteboard too early. For example by
using the filter “(osgi.jaxrs.name=myWhiteboardExtension)”
- The applications that need the extension must also provide a
property for the extension service to recognise so that it can target 
 them
using the *osgi.jaxrs.application.select* filter, for example *extend.me
=true*
- The extension service must then target only these applications
using the *osgi.jaxrs.application.select* filter “(extend.me=true)”


 This sets up the bi-directional targeting that you’re after, while also
 guaranteeing that there are no start-up ordering issues. It is a pretty odd
 situation though.

 More typically a whiteboard extension would just be applied to all of
 the applications in the whiteboard, or just target specific applications.
 You would then place extension requirements on specific whiteboard
 resources that need the extension, not blocking the whole application. This
 is doubly true because whiteboard applications should normally contain
 their mandatory extensions as part of the application, not as whiteboard
 additions.

 Anyway, I hope this helps to clear things up!

 Tim


 On 22 Aug 2017, at 18:34, Bram Pouwelse  wrote:



 On Tue, Aug 22, 2017 at 4:05 PM Raymond Auge 
 wrote:

> On Tue, Aug 22, 2017 at 8:50 AM, Bram Pouwelse  w
> rote:
>
>> Hi all,
>>
>> I have some questions about the "Additional JAX-RS types" section of
>> the JAX-RS-Services RFC (rfc-217).
>>
>> 5.2 Additional JAX-RS types:
>> …​
>> *"Extensions should provide an osgi.jaxrs.application.select property
>> with a filter that will match application to which this extensions will 
>> be
>> registered. If no such filter is provided the extension will affect the
>> default application." *
>> …​
>>
>>
>> 5.2.5 Depending on Extension Services:
>>
>>
>> *"When writing and configuring a JAX-RS resource or extension it is
>> possible for one extension to depend on another. For example a JAX-RS
>> resource may have a dependency upon a MessageBodyWriter to provide JSON
>> serialization, or a ContainerRequestFilter may depend on a 
>> ContextResolver
>> to provide injected configuration.*
>>
>>
>> *In these cases it is necessary to express a dependency on the
>> existence of an extension within the JAX-RS container. This can be
>> expressed on any JAX-RS whiteboard service using the
>> osgi.jaxrs.extension.select property. This property has type String+ and
>> contains a list of LDAP filters. These filters will be run against the
>> service properties of each extension service registered with the 
>> container.
>> If all of the supplied filters pass then the whiteboard service will
>> registered. This extension checking should be done per Application.*
>> *If at some point later a necessary extension service dependency
>> becomes unavailable then the 

Re: [osgi-dev] Questions about JAX-RS Extension services

2017-08-25 Thread Bram Pouwelse
I was more woried about  conflicts, for example a default "*MessageBodyWriter
to provide JSON serialization*" I could register that targeting all
applications but some application could need a customized one?

Bram

On Fri, Aug 25, 2017 at 3:20 PM Raymond Auge 
wrote:

> Binding an extension to every app is pretty much free since only those
> resources/applications/extensions having a dependency on it can/will use
> it! Right?
>
> - Ray
>
> On Thu, Aug 24, 2017 at 3:34 PM, Bram Pouwelse  wrote:
>
>> I was mainly looking for the possibility to register extensions available
>> for multiple applications to use but not bind them to all. The extend.me
>> example in Tim's answer didn't cross my mind but I guess that should do the
>> trick :)
>>
>> Thanks guys!
>>
>> On Wed, Aug 23, 2017 at 11:12 AM Timothy Ward 
>> wrote:
>>
>>> Hi Bram,
>>>
>>> It sounds like you have something of an advanced use case in that you
>>> want to selectively provide a whiteboard extension (which is achieved using
>>> the application select property) and you want to prevent certain
>>> applications from being deployed until a suitable extension is available
>>> (which is achieved using the extension select property).
>>>
>>> The way I would do this is as follows:
>>>
>>>
>>>- All applications that need the extension must express their
>>>dependency using the *osgi.jaxrs.extension.select* filter to prevent
>>>them being picked up by the whiteboard too early. For example by using 
>>> the
>>>filter “(osgi.jaxrs.name=myWhiteboardExtension)”
>>>- The applications that need the extension must also provide a
>>>property for the extension service to recognise so that it can target 
>>> them
>>>using the *osgi.jaxrs.application.select* filter, for example *extend.me
>>>=true*
>>>- The extension service must then target only these applications
>>>using the *osgi.jaxrs.application.select* filter “(extend.me=true)”
>>>
>>>
>>> This sets up the bi-directional targeting that you’re after, while also
>>> guaranteeing that there are no start-up ordering issues. It is a pretty odd
>>> situation though.
>>>
>>> More typically a whiteboard extension would just be applied to all of
>>> the applications in the whiteboard, or just target specific applications.
>>> You would then place extension requirements on specific whiteboard
>>> resources that need the extension, not blocking the whole application. This
>>> is doubly true because whiteboard applications should normally contain
>>> their mandatory extensions as part of the application, not as whiteboard
>>> additions.
>>>
>>> Anyway, I hope this helps to clear things up!
>>>
>>> Tim
>>>
>>>
>>> On 22 Aug 2017, at 18:34, Bram Pouwelse  wrote:
>>>
>>>
>>>
>>> On Tue, Aug 22, 2017 at 4:05 PM Raymond Auge 
>>> wrote:
>>>
 On Tue, Aug 22, 2017 at 8:50 AM, Bram Pouwelse 
 wrote:

> Hi all,
>
> I have some questions about the "Additional JAX-RS types" section of
> the JAX-RS-Services RFC (rfc-217).
>
> 5.2 Additional JAX-RS types:
> …​
> *"Extensions should provide an osgi.jaxrs.application.select property
> with a filter that will match application to which this extensions will be
> registered. If no such filter is provided the extension will affect the
> default application." *
> …​
>
>
> 5.2.5 Depending on Extension Services:
>
>
> *"When writing and configuring a JAX-RS resource or extension it is
> possible for one extension to depend on another. For example a JAX-RS
> resource may have a dependency upon a MessageBodyWriter to provide JSON
> serialization, or a ContainerRequestFilter may depend on a ContextResolver
> to provide injected configuration.*
>
>
> *In these cases it is necessary to express a dependency on the
> existence of an extension within the JAX-RS container. This can be
> expressed on any JAX-RS whiteboard service using the
> osgi.jaxrs.extension.select property. This property has type String+ and
> contains a list of LDAP filters. These filters will be run against the
> service properties of each extension service registered with the 
> container.
> If all of the supplied filters pass then the whiteboard service will
> registered. This extension checking should be done per Application.*
> *If at some point later a necessary extension service dependency
> becomes unavailable then the whiteboard service will become ineligible for
> inclusion in the JAX-RS container until a suitable replacement is found."*
>
>
> Questions:
>
>- Is there a way to register extension services without actively
>adding them to an application (just have them ready to use for those 
> who
>need them)?
>
> Use an 

Re: [osgi-dev] Questions about JAX-RS Extension services

2017-08-25 Thread Raymond Auge
Binding an extension to every app is pretty much free since only those
resources/applications/extensions having a dependency on it can/will use
it! Right?

- Ray

On Thu, Aug 24, 2017 at 3:34 PM, Bram Pouwelse  wrote:

> I was mainly looking for the possibility to register extensions available
> for multiple applications to use but not bind them to all. The extend.me
> example in Tim's answer didn't cross my mind but I guess that should do the
> trick :)
>
> Thanks guys!
>
> On Wed, Aug 23, 2017 at 11:12 AM Timothy Ward 
> wrote:
>
>> Hi Bram,
>>
>> It sounds like you have something of an advanced use case in that you
>> want to selectively provide a whiteboard extension (which is achieved using
>> the application select property) and you want to prevent certain
>> applications from being deployed until a suitable extension is available
>> (which is achieved using the extension select property).
>>
>> The way I would do this is as follows:
>>
>>
>>- All applications that need the extension must express their
>>dependency using the *osgi.jaxrs.extension.select* filter to prevent
>>them being picked up by the whiteboard too early. For example by using the
>>filter “(osgi.jaxrs.name=myWhiteboardExtension)”
>>- The applications that need the extension must also provide a
>>property for the extension service to recognise so that it can target them
>>using the *osgi.jaxrs.application.select* filter, for example *extend.me
>>=true*
>>- The extension service must then target only these applications
>>using the *osgi.jaxrs.application.select* filter “(extend.me=true)”
>>
>>
>> This sets up the bi-directional targeting that you’re after, while also
>> guaranteeing that there are no start-up ordering issues. It is a pretty odd
>> situation though.
>>
>> More typically a whiteboard extension would just be applied to all of the
>> applications in the whiteboard, or just target specific applications. You
>> would then place extension requirements on specific whiteboard resources
>> that need the extension, not blocking the whole application. This is doubly
>> true because whiteboard applications should normally contain their
>> mandatory extensions as part of the application, not as whiteboard
>> additions.
>>
>> Anyway, I hope this helps to clear things up!
>>
>> Tim
>>
>>
>> On 22 Aug 2017, at 18:34, Bram Pouwelse  wrote:
>>
>>
>>
>> On Tue, Aug 22, 2017 at 4:05 PM Raymond Auge 
>> wrote:
>>
>>> On Tue, Aug 22, 2017 at 8:50 AM, Bram Pouwelse  w
>>> rote:
>>>
 Hi all,

 I have some questions about the "Additional JAX-RS types" section of
 the JAX-RS-Services RFC (rfc-217).

 5.2 Additional JAX-RS types:
 …​
 *"Extensions should provide an osgi.jaxrs.application.select property
 with a filter that will match application to which this extensions will be
 registered. If no such filter is provided the extension will affect the
 default application." *
 …​


 5.2.5 Depending on Extension Services:


 *"When writing and configuring a JAX-RS resource or extension it is
 possible for one extension to depend on another. For example a JAX-RS
 resource may have a dependency upon a MessageBodyWriter to provide JSON
 serialization, or a ContainerRequestFilter may depend on a ContextResolver
 to provide injected configuration.*


 *In these cases it is necessary to express a dependency on the
 existence of an extension within the JAX-RS container. This can be
 expressed on any JAX-RS whiteboard service using the
 osgi.jaxrs.extension.select property. This property has type String+ and
 contains a list of LDAP filters. These filters will be run against the
 service properties of each extension service registered with the container.
 If all of the supplied filters pass then the whiteboard service will
 registered. This extension checking should be done per Application.*
 *If at some point later a necessary extension service dependency
 becomes unavailable then the whiteboard service will become ineligible for
 inclusion in the JAX-RS container until a suitable replacement is found."*


 Questions:

- Is there a way to register extension services without actively
adding them to an application (just have them ready to use for those who
need them)?

 Use an `*osgi.jaxrs.application.select` filter than matches all
>>> applications:*
>>> *e.g. **osgi.jaxrs.application.select=*(osgi.jaxrs.name=*)
>>>
>>
>> Maybe my understanding of the rfc is wrong but I'd expect the extension
>> service to be added to all applications, what I'm looking for is having the
>> extension service available for applications that require them but not add
>> them to applications that don't.
>>
>>>
-
- Is