Re: [osgi-dev] ContainerRequestFilter/ContainerResponseFilter life cycle

[Nhut Thai Le via osgi-dev]

Thank you Raymond,

Turn out eclipse oxygen doesn't support DS 1.4 yet so i'll stick with the
Component property for now

Thai

On Wed, Jan 30, 2019 at 1:50 PM Raymond Auge 
wrote:

> You need to make sure that the build tool you are using supports the
> handling of bundle annotations.
>
> This is at minimum bnd 4.1.0 (so maven-bundle-plugin 4.1.0,, Bndtools
> 4.1.0, bnd-maven-plugin 4.1.0). You may be able to get away with bnd 4.0.0
> in some cases, but the support for bundle annotations wasn't quite complete
> yet.
>
> - Ray
>
> On Wed, Jan 30, 2019 at 1:40 PM Nhut Thai Le  wrote:
>
>> Tim,
>>
>> I changed the text properties to annotations:
>>
>> @Component(service = Application.class)
>> @JaxrsName(DiagramConstants.REST_APP)
>> @JaxrsApplicationBase("diagram/services/diagrams/rest")
>> public final class DiagramRestApp extends Application {}
>>
>> But i now see the service xml regenerated in my OSGI-INF folder lost the
>> application base and name properties:
>> 
>> http://www.osgi.org/xmlns/scr/v1.1.0;
>> activate="activate"
>> name="com.castortech.iris.ba.diagrams.provider.servlet.DiagramRestApp">
>>
>>   
>>
>>> class="com.castortech.iris.ba.diagrams.provider.servlet.DiagramRestApp"/>
>> 
>>
>> Inspecting the service also yield that the properties are missing:
>> se javax.ws.rs.core.Application
>> ...
>> {javax.ws.rs.core.Application}={service.id=580, service.bundleid=454,
>> service.scope=bundle, 
>> component.name=com.castortech.iris.ba.diagrams.provider.servlet.DiagramRestApp,
>> component.id=1113}
>>   "Registered by bundle:"
>> com.castortech.iris.ba.diagrams.provider_1.0.0.qualifier [454]
>>   "No bundles using service."
>> ...
>>
>> Thus when i make a request to the REST api, i got 404.
>>
>> Is the missing properties causes aries jaxrs not pickup the service ? If
>> it is, then do you have an idea why the properties is missing when using
>> jaxrs annotations?
>>
>> Thai
>>
>>
>> On Wed, Jan 30, 2019 at 11:56 AM Tim Ward  wrote:
>>
>>>
>>>
>>> On 30 Jan 2019, at 16:52, Nhut Thai Le  wrote:
>>>
>>> Tim,
>>>
>>> Thank you for quickly identify my problems :D, please see my comments
>>> inline
>>>
>>> On Wed, Jan 30, 2019 at 10:13 AM Tim Ward  wrote:
>>>
 Hi,

 Firstly:

 Why does DiagramRestApp do this?

   @Override
   public Set getSingletons() {
   return Collections.singleton(this);
   }


 That is just all kinds of wrong!

>>> i'm using aries-jaxrs-whiteboard for our REST api and i was was looking
 at the test to see how to build the Application class, i think this is what
 i was following:
 https://github.com/apache/aries-jax-rs-whiteboard/blob/master/jax-rs.itests/src/main/java/test/types/TestApplication.java.
 I got some errors at that time without the getSingletons() so i left it
 there. Now i just removed it and it seem fine.

>>>
>>> In this case the TestApplication class is a resource class (it declares
>>> resource methods). It’s still horrible to do this, but it’s being done to
>>> reduce the number of types in the test.
>>>
>>>
 Secondly, you’re using String properties everywhere rather than the
 annotations. This is asking for trouble with typos and inconsistencies.
 You are right, i should change to annotations

 Next:

 The following:

 @Component(
 service = CommonDiagramRESTService.class,
 property = {
 "osgi.jaxrs.extension=true",
 "osgi.jaxrs.name=CommonDiagramRESTService",
 "osgi.jaxrs.application.select=(osgi.jaxrs.name=DiagramRestApp)"
 }
 )
 @Path("/common")
 public final class CommonDiagramRESTService {..}


 and

 @Component(
 service = GridDiagramRESTService.class,
 property = {
  "osgi.jaxrs.extension=true" ,
  "osgi.jaxrs.name=GridDiagramRESTService",
  "osgi.jaxrs.application.select=(osgi.jaxrs.name=DiagramRestApp)"
 }
 )
 @Path("/grid")
 public final class GridDiagramRESTService {...}


 These types declare that they are extensions - why? They don’t
 advertise any extension interfaces. They should advertise themselves as
 resources (which is what they are). I would not expect these to be picked
 up properly by the whiteboard as they are not extensions and they don’t
 advertise being resources.

>>> Sorry, this is my typo, I'm using const so i replaced the const with
>>> their values here so u can see how those classes are related, somehow i
>>> replaced the property osgi.jaxrs.resource=true by
>>> osgi.jaxrs.extension=true when copying here
>>>


 What I observe is that the filter got activated 25 times, although all
 the resource classes and the filter bind to the same jaxrs application. Is
 this normal?


 Depending on the underlying implementation of the whiteboard and the
 registration order of the services this may or may not happen. Some JAX-RS
 implementations 

Re: [osgi-dev] ContainerRequestFilter/ContainerResponseFilter life cycle

[Raymond Auge via osgi-dev]

You need to make sure that the build tool you are using supports the
handling of bundle annotations.

This is at minimum bnd 4.1.0 (so maven-bundle-plugin 4.1.0,, Bndtools
4.1.0, bnd-maven-plugin 4.1.0). You may be able to get away with bnd 4.0.0
in some cases, but the support for bundle annotations wasn't quite complete
yet.

- Ray

On Wed, Jan 30, 2019 at 1:40 PM Nhut Thai Le  wrote:

> Tim,
>
> I changed the text properties to annotations:
>
> @Component(service = Application.class)
> @JaxrsName(DiagramConstants.REST_APP)
> @JaxrsApplicationBase("diagram/services/diagrams/rest")
> public final class DiagramRestApp extends Application {}
>
> But i now see the service xml regenerated in my OSGI-INF folder lost the
> application base and name properties:
> 
> http://www.osgi.org/xmlns/scr/v1.1.0;
> activate="activate"
> name="com.castortech.iris.ba.diagrams.provider.servlet.DiagramRestApp">
>
>   
>
> class="com.castortech.iris.ba.diagrams.provider.servlet.DiagramRestApp"/>
> 
>
> Inspecting the service also yield that the properties are missing:
> se javax.ws.rs.core.Application
> ...
> {javax.ws.rs.core.Application}={service.id=580, service.bundleid=454,
> service.scope=bundle, 
> component.name=com.castortech.iris.ba.diagrams.provider.servlet.DiagramRestApp,
> component.id=1113}
>   "Registered by bundle:"
> com.castortech.iris.ba.diagrams.provider_1.0.0.qualifier [454]
>   "No bundles using service."
> ...
>
> Thus when i make a request to the REST api, i got 404.
>
> Is the missing properties causes aries jaxrs not pickup the service ? If
> it is, then do you have an idea why the properties is missing when using
> jaxrs annotations?
>
> Thai
>
>
> On Wed, Jan 30, 2019 at 11:56 AM Tim Ward  wrote:
>
>>
>>
>> On 30 Jan 2019, at 16:52, Nhut Thai Le  wrote:
>>
>> Tim,
>>
>> Thank you for quickly identify my problems :D, please see my comments
>> inline
>>
>> On Wed, Jan 30, 2019 at 10:13 AM Tim Ward  wrote:
>>
>>> Hi,
>>>
>>> Firstly:
>>>
>>> Why does DiagramRestApp do this?
>>>
>>>   @Override
>>>   public Set getSingletons() {
>>>   return Collections.singleton(this);
>>>   }
>>>
>>>
>>> That is just all kinds of wrong!
>>>
>> i'm using aries-jaxrs-whiteboard for our REST api and i was was looking
>>> at the test to see how to build the Application class, i think this is what
>>> i was following:
>>> https://github.com/apache/aries-jax-rs-whiteboard/blob/master/jax-rs.itests/src/main/java/test/types/TestApplication.java.
>>> I got some errors at that time without the getSingletons() so i left it
>>> there. Now i just removed it and it seem fine.
>>>
>>
>> In this case the TestApplication class is a resource class (it declares
>> resource methods). It’s still horrible to do this, but it’s being done to
>> reduce the number of types in the test.
>>
>>
>>> Secondly, you’re using String properties everywhere rather than the
>>> annotations. This is asking for trouble with typos and inconsistencies.
>>> You are right, i should change to annotations
>>>
>>> Next:
>>>
>>> The following:
>>>
>>> @Component(
>>> service = CommonDiagramRESTService.class,
>>> property = {
>>> "osgi.jaxrs.extension=true",
>>> "osgi.jaxrs.name=CommonDiagramRESTService",
>>> "osgi.jaxrs.application.select=(osgi.jaxrs.name=DiagramRestApp)"
>>> }
>>> )
>>> @Path("/common")
>>> public final class CommonDiagramRESTService {..}
>>>
>>>
>>> and
>>>
>>> @Component(
>>> service = GridDiagramRESTService.class,
>>> property = {
>>>  "osgi.jaxrs.extension=true" ,
>>>  "osgi.jaxrs.name=GridDiagramRESTService",
>>>  "osgi.jaxrs.application.select=(osgi.jaxrs.name=DiagramRestApp)"
>>> }
>>> )
>>> @Path("/grid")
>>> public final class GridDiagramRESTService {...}
>>>
>>>
>>> These types declare that they are extensions - why? They don’t advertise
>>> any extension interfaces. They should advertise themselves as resources
>>> (which is what they are). I would not expect these to be picked up properly
>>> by the whiteboard as they are not extensions and they don’t advertise being
>>> resources.
>>>
>> Sorry, this is my typo, I'm using const so i replaced the const with
>> their values here so u can see how those classes are related, somehow i
>> replaced the property osgi.jaxrs.resource=true by
>> osgi.jaxrs.extension=true when copying here
>>
>>>
>>>
>>> What I observe is that the filter got activated 25 times, although all
>>> the resource classes and the filter bind to the same jaxrs application. Is
>>> this normal?
>>>
>>>
>>> Depending on the underlying implementation of the whiteboard and the
>>> registration order of the services this may or may not happen. Some JAX-RS
>>> implementations are not dynamic, in this case the whole application must be
>>> bounced when a change occurs. This will result in the currently registered
>>> services being discarded and re-created.
>>>
>>> Best Regards,
>>>
>>> Tim
>>>
>>>
>>> On 30 Jan 2019, at 15:01, Nhut Thai Le  wrote:
>>>
>>> Tim,
>>>
>>> I have one jaxrs application:
>>> 

Re: [osgi-dev] ContainerRequestFilter/ContainerResponseFilter life cycle

[Tim Ward via osgi-dev]

> On 30 Jan 2019, at 16:52, Nhut Thai Le  wrote:
> 
> Tim, 
> 
> Thank you for quickly identify my problems :D, please see my comments inline
> 
> On Wed, Jan 30, 2019 at 10:13 AM Tim Ward  > wrote:
> Hi,
> 
> Firstly:
> 
> Why does DiagramRestApp do this?
> 
>>   @Override
>>   public Set getSingletons() {
>>   return Collections.singleton(this);
>>   }
> 
> That is just all kinds of wrong!
> i'm using aries-jaxrs-whiteboard for our REST api and i was was looking at 
> the test to see how to build the Application class, i think this is what i 
> was following: 
> https://github.com/apache/aries-jax-rs-whiteboard/blob/master/jax-rs.itests/src/main/java/test/types/TestApplication.java
>  
> .
>  I got some errors at that time without the getSingletons() so i left it 
> there. Now i just removed it and it seem fine.

In this case the TestApplication class is a resource class (it declares 
resource methods). It’s still horrible to do this, but it’s being done to 
reduce the number of types in the test.

> 
> Secondly, you’re using String properties everywhere rather than the 
> annotations. This is asking for trouble with typos and inconsistencies.
> You are right, i should change to annotations
> 
> Next:
> 
> The following:
> 
>> @Component(
>>  service = CommonDiagramRESTService.class,
>>  property = { 
>>  "osgi.jaxrs.extension=true", 
>>  "osgi.jaxrs.name 
>> =CommonDiagramRESTService", 
>>  "osgi.jaxrs.application.select=(osgi.jaxrs.name 
>> =DiagramRestApp)" 
>>  }
>> )
>> @Path("/common")
>> public final class CommonDiagramRESTService {..}
> 
> 
> and
> 
>> @Component(
>>  service = GridDiagramRESTService.class,
>>  property = { 
>>   "osgi.jaxrs.extension=true" , 
>>   "osgi.jaxrs.name 
>> =GridDiagramRESTService", 
>>   
>> "osgi.jaxrs.application.select=(osgi.jaxrs.name 
>> =DiagramRestApp)"   
>>  }
>> )
>> @Path("/grid")
>> public final class GridDiagramRESTService {...}
> 
> 
> These types declare that they are extensions - why? They don’t advertise any 
> extension interfaces. They should advertise themselves as resources (which is 
> what they are). I would not expect these to be picked up properly by the 
> whiteboard as they are not extensions and they don’t advertise being 
> resources.
> Sorry, this is my typo, I'm using const so i replaced the const with their 
> values here so u can see how those classes are related, somehow i replaced 
> the property osgi.jaxrs.resource=true by osgi.jaxrs.extension=true when 
> copying here
> 
> 
>> What I observe is that the filter got activated 25 times, although all the 
>> resource classes and the filter bind to the same jaxrs application. Is this 
>> normal?
> 
> Depending on the underlying implementation of the whiteboard and the 
> registration order of the services this may or may not happen. Some JAX-RS 
> implementations are not dynamic, in this case the whole application must be 
> bounced when a change occurs. This will result in the currently registered 
> services being discarded and re-created.
> 
> Best Regards,
> 
> Tim
> 
> 
>> On 30 Jan 2019, at 15:01, Nhut Thai Le > > wrote:
>> 
>> Tim,
>> 
>> I have one jaxrs application:
>> @Component(
>>  service = Application.class,
>>  property= {
>>  "osgi.jaxrs.name =DiagramRestApp",
>>  "osgi.jaxrs.application.base=/diagram/services/diagrams/rest"
>>  }
>> )
>> public final class DiagramRestApp extends Application {
>>   @Override
>>   public Set getSingletons() {
>>   return Collections.singleton(this);
>>   }
>> }
>> but multiple resource classes, about 25 of them, here is one
>> @Component(
>>  service = CommonDiagramRESTService.class,
>>  property = { 
>>  "osgi.jaxrs.extension=true", 
>>  "osgi.jaxrs.name 
>> =CommonDiagramRESTService", 
>>  "osgi.jaxrs.application.select=(osgi.jaxrs.name 
>> =DiagramRestApp)" 
>>  }
>> )
>> @Path("/common")
>> public final class CommonDiagramRESTService {..}
>> 
>> and another one:
>> @Component(
>>  service = GridDiagramRESTService.class,
>>  property = { 
>>   "osgi.jaxrs.extension=true" , 
>>   "osgi.jaxrs.name 
>> =GridDiagramRESTService", 
>>   
>> 

Re: [osgi-dev] ContainerRequestFilter/ContainerResponseFilter life cycle

[Nhut Thai Le via osgi-dev]

Tim,

Thank you for quickly identify my problems :D, please see my comments inline

On Wed, Jan 30, 2019 at 10:13 AM Tim Ward  wrote:

> Hi,
>
> Firstly:
>
> Why does DiagramRestApp do this?
>
>   @Override
>   public Set getSingletons() {
>   return Collections.singleton(this);
>   }
>
>
> That is just all kinds of wrong!
>
i'm using aries-jaxrs-whiteboard for our REST api and i was was looking at
> the test to see how to build the Application class, i think this is what i
> was following:
> https://github.com/apache/aries-jax-rs-whiteboard/blob/master/jax-rs.itests/src/main/java/test/types/TestApplication.java.
> I got some errors at that time without the getSingletons() so i left it
> there. Now i just removed it and it seem fine.
>

> Secondly, you’re using String properties everywhere rather than the
> annotations. This is asking for trouble with typos and inconsistencies.
> You are right, i should change to annotations
>
> Next:
>
> The following:
>
> @Component(
> service = CommonDiagramRESTService.class,
> property = {
> "osgi.jaxrs.extension=true",
> "osgi.jaxrs.name=CommonDiagramRESTService",
> "osgi.jaxrs.application.select=(osgi.jaxrs.name=DiagramRestApp)"
> }
> )
> @Path("/common")
> public final class CommonDiagramRESTService {..}
>
>
> and
>
> @Component(
> service = GridDiagramRESTService.class,
> property = {
>  "osgi.jaxrs.extension=true" ,
>  "osgi.jaxrs.name=GridDiagramRESTService",
>  "osgi.jaxrs.application.select=(osgi.jaxrs.name=DiagramRestApp)"
> }
> )
> @Path("/grid")
> public final class GridDiagramRESTService {...}
>
>
> These types declare that they are extensions - why? They don’t advertise
> any extension interfaces. They should advertise themselves as resources
> (which is what they are). I would not expect these to be picked up properly
> by the whiteboard as they are not extensions and they don’t advertise being
> resources.
>
Sorry, this is my typo, I'm using const so i replaced the const with their
values here so u can see how those classes are related, somehow i replaced
the property osgi.jaxrs.resource=true by osgi.jaxrs.extension=true when
copying here

>
>
> What I observe is that the filter got activated 25 times, although all the
> resource classes and the filter bind to the same jaxrs application. Is this
> normal?
>
>
> Depending on the underlying implementation of the whiteboard and the
> registration order of the services this may or may not happen. Some JAX-RS
> implementations are not dynamic, in this case the whole application must be
> bounced when a change occurs. This will result in the currently registered
> services being discarded and re-created.
>
> Best Regards,
>
> Tim
>
>
> On 30 Jan 2019, at 15:01, Nhut Thai Le  wrote:
>
> Tim,
>
> I have one jaxrs application:
> @Component(
> service = Application.class,
> property= {
> "osgi.jaxrs.name=DiagramRestApp",
> "osgi.jaxrs.application.base=/diagram/services/diagrams/rest"
> }
> )
> public final class DiagramRestApp extends Application {
>   @Override
>   public Set getSingletons() {
>   return Collections.singleton(this);
>   }
> }
> but multiple resource classes, about 25 of them, here is one
> @Component(
> service = CommonDiagramRESTService.class,
> property = {
> "osgi.jaxrs.extension=true",
> "osgi.jaxrs.name=CommonDiagramRESTService",
> "osgi.jaxrs.application.select=(osgi.jaxrs.name=DiagramRestApp)"
> }
> )
> @Path("/common")
> public final class CommonDiagramRESTService {..}
>
> and another one:
> @Component(
> service = GridDiagramRESTService.class,
> property = {
> "osgi.jaxrs.extension=true" ,
>  "osgi.jaxrs.name=GridDiagramRESTService",
> "osgi.jaxrs.application.select=(osgi.jaxrs.name=DiagramRestApp)"
> }
> )
> @Path("/grid")
> public final class GridDiagramRESTService {...}
>
> and finally my jaxrs filter:
> @Component(
> service = {
> ContainerRequestFilter.class,
> ContainerResponseFilter.class
> },
> scope = ServiceScope.PROTOTYPE,
> property = {
> "osgi.jaxrs.extension=true",
> "osgi.jaxrs.name=DiagramRestFilter",
> "osgi.jaxrs.application.select=(osgi.jaxrs.name=DiagramRestApp)"
> }
> )
> @PreMatching
> @Priority(Priorities.AUTHENTICATION)
> public final class DiagramRestFilter extends
> OsgiJaxrsBearerTokenFilterImpl implements ContainerResponseFilter {..}
>
> What I observe is that the filter got activated 25 times, although all the
> resource classes and the filter bind to the same jaxrs application. Is this
> normal?
>
> Thai
>
> On Tue, Jan 29, 2019 at 11:17 AM Nhut Thai Le  wrote:
>
>> Thank you for clarifying.
>>
>> Thai
>>
>>
>>
>> On Tue, Jan 29, 2019 at 10:24 AM Tim Ward  wrote:
>>
>>> Hi,
>>>
>>> As described in the JAX-RS Whiteboard spec
>>> 
>>>  JAX-RS
>>> extension instances are required to be singletons (I’m talking about the
>>> objects, not the services) by the JAX-RS specification itself. Therefore
>>> within an application you will only ever see one instance of a whiteboard
>>> 

Re: [osgi-dev] ContainerRequestFilter/ContainerResponseFilter life cycle

[Nhut Thai Le via osgi-dev]

Thank you for clarifying.

Thai



On Tue, Jan 29, 2019 at 10:24 AM Tim Ward  wrote:

> Hi,
>
> As described in the JAX-RS Whiteboard spec
>  
> JAX-RS
> extension instances are required to be singletons (I’m talking about the
> objects, not the services) by the JAX-RS specification itself. Therefore
> within an application you will only ever see one instance of a whiteboard
> extension service.
>
> The reason that you should make extension services prototype is therefore
> not related to per-request handling, but instead because of what happens
> when the same extension service is applied to *multiple applications*. In
> this scenario you will have multiple applications with different
> configuration and different context objects. If your extension service is
> injected with these objects by the JAX-RS runtime (for example being
> injected with the Application using @Context) then which application is
> that for? In the general case you have no idea whether the context object
> you have been injected with relates to the current request or not.
>
> If your extension service is singleton or bundle scoped then the JAX-RS
> whiteboard can only get one instance. It therefore has to use this same
> instance for all of the whiteboard applications and you run into the
> potential “multiple injections” trap. This is obviously fine if you don’t
> have any injection sites, or if all your injection sites are method
> parameters, but it is a risky thing to do as someone may add an injection
> site later without realising that they’ve broken things. This will probably
> also make it through testing as you’ll typically only have one application
> at a time when testing!
>
> If your extension service is prototype scope then the JAX-RS Whiteboard is
> able to get a different instance to use in each whiteboard application. At
> this point you no longer need to worry about multiple injections because
> the injections happen on different instances.
>
> I hope this answers your question, and helps to further explain why
> prototype scope is a good thing for filters!
>
> Best Regards,
>
> Tim
>
> On 29 Jan 2019, at 15:18, Raymond Auge via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> I'm going to assume you are talking about:
>
> HttpService[1] or Http Whiteboard[2] w.r.t. the reference to Servlet
> AND
> JAX-RS Whiteboard[3] w.r.t. the reference to ContainerRequestFilter
>
> These 2(3) features are separate concerns and the ContainerRequestFilter
> of the JAX-RS whiteboard spec doesn't apply to the Servlets of the Http
> Whiteboard. You probably just want a regular old servlet Filter[4]
>
> Now it's possible that you are talking about some other runtime that packs
> all these things together. If so, you probably want to ask the implementors
> about this.
>
> Hope that helps clear things up,
> - Ray
>
> [1] https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.html
> [2]
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html
> [3] https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html
> [4]
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#d0e121055
>
> On Tue, Jan 29, 2019 at 9:59 AM Nhut Thai Le via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Hello,
>>
>> I have a component implementing ContainerRequestFilter to intercept REST
>> calls and another component implements servlet.Filter. Both have PROTOTYPE
>> scope, my understanding is that these filter are instantiated and activated
>> for each web request but yesterday when i put some breakpoints in
>> the @activate method, i did not see them get called when a web request
>> arrives. Did I miss something? If they are not init/activate per request
>> why are they recomeded to be prototype?
>>
>> Thai Le
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>

-- 
Castor Technologies Inc
460 rue St-Catherine St Ouest, Suite 613
Montréal, Québec H3B-1A7
(514) 360-7208 o
(514) 798-2044 f
n...@castortech.com
www.castortech.com

CONFIDENTIALITY NOTICE: The information contained in this e-mail is
confidential and may be proprietary information intended only for the use
of the individual or entity to whom it is addressed. If the reader of this
message is not the intended recipient, you are hereby notified that any
viewing, dissemination, distribution, disclosure, copy or use of the
information contained in this e-mail message 

Re: [osgi-dev] ContainerRequestFilter/ContainerResponseFilter life cycle

[Tim Ward via osgi-dev]

Hi,

As described in the JAX-RS Whiteboard spec 
 
JAX-RS extension instances are required to be singletons (I’m talking about the 
objects, not the services) by the JAX-RS specification itself. Therefore within 
an application you will only ever see one instance of a whiteboard extension 
service.

The reason that you should make extension services prototype is therefore not 
related to per-request handling, but instead because of what happens when the 
same extension service is applied to *multiple applications*. In this scenario 
you will have multiple applications with different configuration and different 
context objects. If your extension service is injected with these objects by 
the JAX-RS runtime (for example being injected with the Application using 
@Context) then which application is that for? In the general case you have no 
idea whether the context object you have been injected with relates to the 
current request or not.

If your extension service is singleton or bundle scoped then the JAX-RS 
whiteboard can only get one instance. It therefore has to use this same 
instance for all of the whiteboard applications and you run into the potential 
“multiple injections” trap. This is obviously fine if you don’t have any 
injection sites, or if all your injection sites are method parameters, but it 
is a risky thing to do as someone may add an injection site later without 
realising that they’ve broken things. This will probably also make it through 
testing as you’ll typically only have one application at a time when testing!

If your extension service is prototype scope then the JAX-RS Whiteboard is able 
to get a different instance to use in each whiteboard application. At this 
point you no longer need to worry about multiple injections because the 
injections happen on different instances.

I hope this answers your question, and helps to further explain why prototype 
scope is a good thing for filters!

Best Regards,

Tim

> On 29 Jan 2019, at 15:18, Raymond Auge via osgi-dev  
> wrote:
> 
> I'm going to assume you are talking about:
> 
> HttpService[1] or Http Whiteboard[2] w.r.t. the reference to Servlet
> AND
> JAX-RS Whiteboard[3] w.r.t. the reference to ContainerRequestFilter
> 
> These 2(3) features are separate concerns and the ContainerRequestFilter of 
> the JAX-RS whiteboard spec doesn't apply to the Servlets of the Http 
> Whiteboard. You probably just want a regular old servlet Filter[4]
> 
> Now it's possible that you are talking about some other runtime that packs 
> all these things together. If so, you probably want to ask the implementors 
> about this.
> 
> Hope that helps clear things up,
> - Ray
> 
> [1] https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.html 
> 
> [2] 
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html 
> 
> [3] https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html 
> 
> [4] 
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#d0e121055
>  
> 
> 
> On Tue, Jan 29, 2019 at 9:59 AM Nhut Thai Le via osgi-dev 
> mailto:osgi-dev@mail.osgi.org>> wrote:
> Hello,
> 
> I have a component implementing ContainerRequestFilter to intercept REST 
> calls and another component implements servlet.Filter. Both have PROTOTYPE 
> scope, my understanding is that these filter are instantiated and activated 
> for each web request but yesterday when i put some breakpoints in the 
> @activate method, i did not see them get called when a web request arrives. 
> Did I miss something? If they are not init/activate per request why are they 
> recomeded to be prototype?
> 
> Thai Le
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org 
> https://mail.osgi.org/mailman/listinfo/osgi-dev 
> 
> 
> -- 
> Raymond Augé  (@rotty3000)
> Senior Software Architect Liferay, Inc.  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] ContainerRequestFilter/ContainerResponseFilter life cycle

[Raymond Auge via osgi-dev]

I'm going to assume you are talking about:

HttpService[1] or Http Whiteboard[2] w.r.t. the reference to Servlet
AND
JAX-RS Whiteboard[3] w.r.t. the reference to ContainerRequestFilter

These 2(3) features are separate concerns and the ContainerRequestFilter of
the JAX-RS whiteboard spec doesn't apply to the Servlets of the Http
Whiteboard. You probably just want a regular old servlet Filter[4]

Now it's possible that you are talking about some other runtime that packs
all these things together. If so, you probably want to ask the implementors
about this.

Hope that helps clear things up,
- Ray

[1] https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.html
[2]
https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html
[3] https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html
[4]
https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#d0e121055

On Tue, Jan 29, 2019 at 9:59 AM Nhut Thai Le via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hello,
>
> I have a component implementing ContainerRequestFilter to intercept REST
> calls and another component implements servlet.Filter. Both have PROTOTYPE
> scope, my understanding is that these filter are instantiated and activated
> for each web request but yesterday when i put some breakpoints in
> the @activate method, i did not see them get called when a web request
> arrives. Did I miss something? If they are not init/activate per request
> why are they recomeded to be prototype?
>
> Thai Le
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] ContainerRequestFilter/ContainerResponseFilter life cycle

[Nhut Thai Le via osgi-dev]

Hello,

I have a component implementing ContainerRequestFilter to intercept REST
calls and another component implements servlet.Filter. Both have PROTOTYPE
scope, my understanding is that these filter are instantiated and activated
for each web request but yesterday when i put some breakpoints in
the @activate method, i did not see them get called when a web request
arrives. Did I miss something? If they are not init/activate per request
why are they recomeded to be prototype?

Thai Le
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev