[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Eliminating osgi locator shade

We can scope it for >= java 6 specs if that's the only blocker we hit. This is perfectly fine IMHO.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book

Le mer. 16 mai 2018 à 22:28, David Jencks <david.a.jencks@xxxxxxxxx> a écrit :
It’s been a really long time since I looked at any of this and I might not remember accurately or understand the scope of what you propose to do .... IIRC there were a few specs that predate ServiceLoader and use something similar but incompatible that the locator takes care of. So, you might have trouble removing the locator code everywhere.

David Jencks 

Sent from my iPhone

On May 16, 2018, at 9:32 AM, Raymond Auge <raymond.auge@xxxxxxxxxxx> wrote:

Hello All,

Romain mentioned in another thread about wanting to eliminate the osgi locator shade. I would be super happy to make this happen.

This can be accomplished by leveraging the Service Loader Mediator. However there is a caveat. In order to stick with the Service Mediator spec, the code in question must be using the method


This is to ensure that proper weaving can be accomplished at runtime.

In testing, I applied the required metadata on geronimo-jsonb_1.0_spec and this worked fine, however jsonb depends on jsonp (for instance geronimo-jsonp_1.1_spec) which, when I use these to gether, I found geronimo-jsonp_1.x_spec does not use ServiceLoader at all, but rather a self implementation of such [1].

Would it be fair to replace the self implemented logic with the logic found in the geronimo-jsonb [2] which does the same but using ServiceLoader?

Finally, if the goal is to enable Service Loader Mediator to replace all osgi locator, then we need to ensure this pattern is followed throughout. Does that seem fair? If so I can go through and apply the fix in many places.

- Ray

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