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]<mailto:[email protected]>> wrote: On Thu, May 17, 2018 at 10:52 AM, David Bosschaert <[email protected]<mailto:[email protected]>> 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]<mailto:[email protected]>> wrote: On Thu, May 17, 2018 at 9:44 AM, Pierre De Rop <[email protected]<mailto:[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]<mailto:[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 <[email protected]<mailto:[email protected]>> 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]<mailto:[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)
