Understood, but you won't win that battle with Java EE APIs because for better or worse they mandate the use of service loader.
The goal for Service Loader Mediator is still valid in this respect and seems the only viable course of action. The specific use case I'm working on are the Apache Geronimo Java EE Spec API jars. - Ray On Mon, May 21, 2018, 05:35 Timothy Ward, <timothyjw...@apache.org> wrote: > The best option is, of course, to avoid using ServiceLoader as far as > possible and to use injection to obtain the services. This way your Java SE > injection container can use ServiceLoader (or whatever else it wants) and > you can use OSGi services when in OSGi… > > Tim > > On 18 May 2018, at 21:41, Raymond Auge <raymond.a...@liferay.com> wrote: > > > > On Thu, May 17, 2018 at 10:52 AM, David Bosschaert < > david.bosscha...@gmail.com> wrote: > >> Yeah, thinking more about it, the way it uses a weaving hook it currently >> expects to be started before other bundles. Thanks @Pierre for reminding us >> of that! >> >> I don't really like this ordering either though. Just a couple of >> thoughts from my side: >> * if you use static weaving this problem goes away, as the woven classes >> are put inside the bundle - @Ray would static weaving be an option for you? >> > > Static weaving means that you cannot reuse the bundle outside of OSGi. For > instance, it would be great to contribute appropriate service loader > mediator data to Java EE and like API artifacts. This metadata has no > effect outside of OSGi, but when used in OSGi it makes the API behave > appropriately which is great. > > >> * with dynamic weaving it should be possible to enhance SPI Fly so that >> it can act on existing bundles by refreshing them. Would this make sense >> for this use-case? >> > > I believe this is the approach I would prefer. > > - Ray > > >> >> Best regards, >> >> David >> >> On 17 May 2018 at 15:53, Raymond Auge <raymond.a...@liferay.com> wrote: >> >>> On Thu, May 17, 2018 at 9:44 AM, Pierre De Rop <pierre.de...@gmail.com> >>> wrote: >>> >>>> Hi Ray, David; >>>> >>>> I was thinking that the org.apache.aries.spifly.dynamic.bundle should >>>> be started before all other bundles ? >>>> David, am I correct ? (see http://aries.apache.org/modules/spi-fly.html, >>>> in section "Use with Dynamic Weaving") >>>> >>> >>> Pierre, got it! I missed that part. Thanks for letting me know. This >>> makes a significant difference :) >>> >>> It's too bad because the impl does try to retroactively operate on >>> bundles. It just fails in some scenarios and succeeds in others, which is >>> why I wasn't sure. >>> >>> Sincerely, >>> - Ray >>> >>> >>>> >>>> cheers >>>> Pierre >>>> >>>> On Thu, May 17, 2018 at 12:42 PM, Raymond Auge < >>>> raymond.a...@liferay.com> wrote: >>>> >>>>> Ok, that's all I needed to hear. I'll file a bug report and try to >>>>> make a test case. >>>>> >>>>> Thanks, >>>>> - Ray >>>>> >>>>> On Thu, May 17, 2018 at 1:24 AM, David Bosschaert < >>>>> david.bosscha...@gmail.com> wrote: >>>>> >>>>>> Hi Ray, >>>>>> >>>>>> Sounds like a bug to me. It shouldn't be restricted by start >>>>>> ordering. Would it be possible to file a bug? >>>>>> >>>>>> Best regards, >>>>>> >>>>>> David >>>>>> >>>>>> On 16 May 2018 at 18:38, Raymond Auge <raymond.a...@liferay.com> >>>>>> wrote: >>>>>> >>>>>>> Is the Service Loader Mediator known to be constrained by start >>>>>>> ordering? >>>>>>> >>>>>>> In other words, I'm finding that spifly is having issues when not >>>>>>> "started" before other bundles that specify the requirements and or >>>>>>> capabilities on osgi.serviceloader. >>>>>>> >>>>>>> -- >>>>>>> *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) >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *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) >>>>> >>>> >>>> >>> >>> >>> -- >>> *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) >>> >> >> > > > -- > *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) > > >
