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<Object> 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 <n...@castortech.com> wrote:
> Thank you for clarifying.
>
> Thai
>
>
>
> On Tue, Jan 29, 2019 at 10:24 AM Tim Ward <tim.w...@paremus.com> wrote:
>
>> Hi,
>>
>> As described in the JAX-RS Whiteboard spec
>> <https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#d0e133685>
>> 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é* <http://www.liferay.com/web/raymond.auge/profile>
>> (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>> (@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 is strictly prohibited. If you
> have received and/or are viewing this e-mail in error, please immediately
> notify the sender by reply e-mail, and delete it from your system without
> reading, forwarding, copying or saving in any manner. Thank you.
> AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est
> confidentiel, peut être protégé par le secret professionnel et est réservé
> à l'usage exclusif du destinataire. Toute autre personne est par les
> présentes avisée qu'il lui est strictement interdit de diffuser, distribuer
> ou reproduire ce message. Si vous avez reçu cette communication par erreur,
> veuillez la détruire immédiatement et en aviser l'expéditeur. Merci.
>
--
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 is strictly prohibited. If you
have received and/or are viewing this e-mail in error, please immediately
notify the sender by reply e-mail, and delete it from your system without
reading, forwarding, copying or saving in any manner. Thank you.
AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est
confidentiel, peut être protégé par le secret professionnel et est réservé
à l'usage exclusif du destinataire. Toute autre personne est par les
présentes avisée qu'il lui est strictement interdit de diffuser, distribuer
ou reproduire ce message. Si vous avez reçu cette communication par erreur,
veuillez la détruire immédiatement et en aviser l'expéditeur. Merci.
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
