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> wrote: >> >>> 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
