Precisely. SPI-Fly (and the OSGi ServiceLoader Mediator spec, that it implements) are for those cases where you have to use ServiceLoader in OSGi.
I think the best think to do here is to create a JIRA for it so that someone can pick it up and work on it. As Pierre says, it's not a bug as the ordering is currently described behaviour, so it would be an enhancement... Best regards, David On 21 May 2018 at 16:20, Raymond Auge <[email protected]> wrote: > 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, <[email protected]> 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 <[email protected]> wrote: >> >> >> >> On Thu, May 17, 2018 at 10:52 AM, David Bosschaert <david.bosschaert@ >> 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 <[email protected]> wrote: >>> >>>> On Thu, May 17, 2018 at 9:44 AM, Pierre De Rop <[email protected]> >>>> 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 < >>>>> [email protected]> 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.bosschaert@ >>>>>> 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 <[email protected]> >>>>>>> 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) >> >> >>
