I was more woried about conflicts, for example a default "*MessageBodyWriter to provide JSON serialization*" I could register that targeting all applications but some application could need a customized one?
Bram On Fri, Aug 25, 2017 at 3:20 PM Raymond Auge <raymond.a...@liferay.com> wrote: > 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> >>>> 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 >> > > > > -- > *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
