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=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 > <mailto:raymond.a...@liferay.com>> wrote: > On Tue, Aug 22, 2017 at 8:50 AM, Bram Pouwelse <b...@pouwelse.com > <mailto: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 > <http://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 <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>_______________________________________________ > 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>
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
