The spec states ".. static extensions being ranked below all whiteboard services".
- Ray On Fri, Aug 25, 2017 at 9:51 AM, Bram Pouwelse <b...@pouwelse.com> wrote: > I think the service ranking trick could work but .. what about an > application that has a custom one defined in the application itself? > > On Fri, Aug 25, 2017 at 3:46 PM Tim Ward <tim.w...@paremus.com> wrote: > >> In that case register the custom one targeting that exact application, >> and give it a higher service ranking than the default writer. >> >> Tim >> >> Sent from my iPhone >> >> On 25 Aug 2017, at 14:26, 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 >> >> _______________________________________________ >> 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
