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 <raymond.a...@liferay.com> 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, <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.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 <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.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 <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)
>>
>>
>>

Reply via email to