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
