Simply publish your "shared" extension with a low service ranking!
Finally, if an application needs a specific one, they need to depend on it anyway! - Ray On Fri, Aug 25, 2017 at 9:26 AM, Bram Pouwelse <b...@pouwelse.com> wrote: > 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> 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 > > > _______________________________________________ > 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
