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=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é (@rotty3000) >>>>>> Senior Software Architect Liferay, Inc. (@Liferay) >>>>>> Board Member & EEG Co-Chair, OSGi Alliance (@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é (@rotty3000) >> Senior Software Architect Liferay, Inc. (@Liferay) >> Board Member & EEG Co-Chair, OSGi Alliance (@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
