Thank you for clarifying. Thai
On Tue, Jan 29, 2019 at 10:24 AM Tim Ward <[email protected]> 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 < > [email protected]> 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 < > [email protected]> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] 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 [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
