Re: Service Loader Mediator (spifly)

2018-05-21 Thread David Bosschaert 
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  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,  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  wrote:
>>
>>
>>
>> On Thu, May 17, 2018 at 10:52 AM, 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  wrote:
>>>
 On Thu, May 17, 2018 at 9:44 AM, Pierre De Rop 
  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 > 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 
>>> 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é* 
  (@rotty3000)
 Senior Software Architect *Liferay, Inc.* 
  (@Liferay)
 Board Member & EEG Co-Chair, OSGi Alliance 
 (@OSGiAlliance)

>>>
>>>
>>
>>
>> --
>> *Raymond Augé* 
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* 
>>  (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance 
>> (@OSGiAlliance)
>>
>
>


 --
 *Raymond Augé* 
  (@rotty3000)
 Senior Software

Re: Service Loader Mediator (spifly)

2018-05-21 Thread Raymond Auge 
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,  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  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  wrote:
>>
>>> On Thu, May 17, 2018 at 9:44 AM, Pierre De Rop 
>>> 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 
>> 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é* 
>>>  (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* 
>>>  (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance 
>>> (@OSGiAlliance)
>>>
>>
>>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>


>>>
>>>
>>> --
>>> *Raymond Augé* 
>>>  (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* 
>>>  (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance 
>>> (@OSGiAlliance)
>>>
>>
>>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>
>
>

Re: Service Loader Mediator (spifly)

2018-05-21 Thread Timothy Ward 
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 
> wrote:



On Thu, May 17, 2018 at 10:52 AM, David Bosschaert 
> 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 
> wrote:
On Thu, May 17, 2018 at 9:44 AM, Pierre De Rop 
> 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 
> 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 
> 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 
> 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é (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)




--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)




--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)




--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

Re: Service Loader Mediator (spifly)

2018-05-18 Thread Raymond Auge 
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  wrote:
>
>> On Thu, May 17, 2018 at 9:44 AM, Pierre De Rop 
>> 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 >> > 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 
> 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é* 
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* 
>>  (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance 
>> (@OSGiAlliance)
>>
>
>


 --
 *Raymond Augé* 
  (@rotty3000)
 Senior Software Architect *Liferay, Inc.* 
  (@Liferay)
 Board Member & EEG Co-Chair, OSGi Alliance 
 (@OSGiAlliance)

>>>
>>>
>>
>>
>> --
>> *Raymond Augé* 
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* 
>>  (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance 
>> (@OSGiAlliance)
>>
>
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: Service Loader Mediator (spifly)

2018-05-17 Thread David Bosschaert 
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?
* 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?

Best regards,

David

On 17 May 2018 at 15:53, Raymond Auge  wrote:

> On Thu, May 17, 2018 at 9:44 AM, Pierre De Rop 
> 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 
>> 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  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é* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>


>>>
>>>
>>> --
>>> *Raymond Augé* 
>>>  (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* 
>>>  (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance 
>>> (@OSGiAlliance)
>>>
>>
>>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>

Re: Service Loader Mediator (spifly)

2018-05-17 Thread Raymond Auge 
On Thu, May 17, 2018 at 9:44 AM, Pierre De Rop 
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 
> 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  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é* 
  (@rotty3000)
 Senior Software Architect *Liferay, Inc.* 
  (@Liferay)
 Board Member & EEG Co-Chair, OSGi Alliance 
 (@OSGiAlliance)

>>>
>>>
>>
>>
>> --
>> *Raymond Augé* 
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* 
>>  (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance 
>> (@OSGiAlliance)
>>
>
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: Service Loader Mediator (spifly)

2018-05-17 Thread Pierre De Rop 
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")

cheers
Pierre

On Thu, May 17, 2018 at 12:42 PM, Raymond Auge 
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  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é* 
>>>  (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* 
>>>  (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance 
>>> (@OSGiAlliance)
>>>
>>
>>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>

Re: Service Loader Mediator (spifly)

2018-05-17 Thread Raymond Auge 
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  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é* 
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* 
>>  (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance 
>> (@OSGiAlliance)
>>
>
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: Service Loader Mediator (spifly)

2018-05-16 Thread David Bosschaert 
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  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é* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>