Service Loader Mediator (spifly)

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Service Loader Mediator (spifly)

Raymond Auge
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)
Reply | Threaded
Open this post in threaded view
|

Re: Service Loader Mediator (spifly)

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 <[hidden email]> 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)

Reply | Threaded
Open this post in threaded view
|

Re: Service Loader Mediator (spifly)

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 <[hidden email]> 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 <[hidden email]> 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)
Reply | Threaded
Open this post in threaded view
|

Re: Service Loader Mediator (spifly)

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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)

Reply | Threaded
Open this post in threaded view
|

Re: Service Loader Mediator (spifly)

Raymond Auge
On Thu, May 17, 2018 at 9:44 AM, Pierre De Rop <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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)
Reply | Threaded
Open this post in threaded view
|

Re: Service Loader Mediator (spifly)

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 <[hidden email]> wrote:
On Thu, May 17, 2018 at 9:44 AM, Pierre De Rop <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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)

Reply | Threaded
Open this post in threaded view
|

Re: Service Loader Mediator (spifly)

Raymond Auge


On Thu, May 17, 2018 at 10:52 AM, David Bosschaert <[hidden email]> 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 <[hidden email]> wrote:
On Thu, May 17, 2018 at 9:44 AM, Pierre De Rop <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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)
Reply | Threaded
Open this post in threaded view
|

Re: Service Loader Mediator (spifly)

Timothy Ward-2
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 <[hidden email]> wrote:



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

Reply | Threaded
Open this post in threaded view
|

Re: Service Loader Mediator (spifly)

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, <[hidden email]> 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 <[hidden email]> wrote:



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

Reply | Threaded
Open this post in threaded view
|

Re: Service Loader Mediator (spifly)

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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> wrote:



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