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 <b...@pouwelse.com> 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 <tim.w...@paremus.com> > 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 >> <http://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 <b...@pouwelse.com> wrote: >> >> >> >> On Tue, Aug 22, 2017 at 4:05 PM Raymond Auge <raymond.a...@liferay.com> >> wrote: >> >>> On Tue, Aug 22, 2017 at 8:50 AM, Bram Pouwelse <b...@pouwelse.com> 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 it possible to use an extension service from an application >>>> that doesn’t match the extension service’s osgi.jaxrs.application.select >>>> filter? >>>> >>>> No, since the jax-rs service's extension bindings must come from within >>> those bound to the same application! >>> >> >> :) >> >>> >>>> - >>>> - The "This extension checking should be done per Application" >>>> remark shoud that also apply to the default application? Sounds ok to me >>>> for JAX-RS applications that are registered as such but for the default >>>> application this is kind of strange as a single resource depending on an >>>> unavailable extension could make the whiteboard go down for all JAX-RS >>>> resources (that are not part of an application)? >>>> >>>> Resources which are static need to use static extensions. The spec is >>> only talking about jaxrs "services". Otherwise statically wired resources >>> within a given application are not subject to OSGi services, except from >>> purely the shadowing perspective, not from the wiring/class space >>> perspective. If you're talking about something else could you please >>> elaborate? >>> >> >>> >>>> >>>> - I think for the default application just excluding the resource >>>> with unstatisfied dependencies would be better than taking the default >>>> application down. >>>> >>>> At no point does an application get taken down due to a >>> resource/extension not being satisfied... unless it's the application >>> itself has the extension dependency. But the default application has no >>> such dependencies, in fact it may have no resources either. >>> >>> >> At no point does an application get taken down due to a >> resource/extension not being satisfied >> >> Ok that sounds good :) maybe the "This extension checking should be done >> per Application" part made me overthink things a bit too much >> >> >>> HTH >>> - Ray >>> >>> >>>> >>>> - >>>> >>>> Regards, >>>> Bram >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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
