Hi,
Firstly:
Why does DiagramRestApp do this?
> @Override
> public Set<Object> getSingletons() {
> return Collections.singleton(this);
> }
That is just all kinds of wrong!
Secondly, you’re using String properties everywhere rather than the
annotations. This is asking for trouble with typos and inconsistencies.
Next:
The following:
> @Component(
> service = CommonDiagramRESTService.class,
> property = {
> "osgi.jaxrs.extension=true",
> "osgi.jaxrs.name
> <http://osgi.jaxrs.name/>=CommonDiagramRESTService",
> "osgi.jaxrs.application.select=(osgi.jaxrs.name
> <http://osgi.jaxrs.name/>=DiagramRestApp)"
> }
> )
> @Path("/common")
> public final class CommonDiagramRESTService {..}
and
> @Component(
> service = GridDiagramRESTService.class,
> property = {
> "osgi.jaxrs.extension=true" ,
> "osgi.jaxrs.name
> <http://osgi.jaxrs.name/>=GridDiagramRESTService",
>
> "osgi.jaxrs.application.select=(osgi.jaxrs.name
> <http://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.
> 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 <n...@castortech.com> wrote:
>
> Tim,
>
> I have one jaxrs application:
> @Component(
> service = Application.class,
> property= {
> "osgi.jaxrs.name <http://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
> <http://osgi.jaxrs.name/>=CommonDiagramRESTService",
> "osgi.jaxrs.application.select=(osgi.jaxrs.name
> <http://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
> <http://osgi.jaxrs.name/>=GridDiagramRESTService",
>
> "osgi.jaxrs.application.select=(osgi.jaxrs.name
> <http://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 <http://osgi.jaxrs.name/>=DiagramRestFilter",
> "osgi.jaxrs.application.select=(osgi.jaxrs.name
> <http://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
> <mailto:n...@castortech.com>> wrote:
> Thank you for clarifying.
>
> Thai
>
>
>
> On Tue, Jan 29, 2019 at 10:24 AM Tim Ward <tim.w...@paremus.com
> <mailto: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
>> <mailto: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
>> <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
>> <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
>> <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
>>
>> <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 <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 <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <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 <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <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 <mailto:n...@castortech.com>
> www.castortech.com <http://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 <mailto:n...@castortech.com>
> www.castortech.com <http://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
