[Architecture Board] recommendations and consideration for OSGi interoperability

[rotty3000]

I know that there is a degree of interest in the MicroProfile community with respect to ensuring OSGi interoperability. I wanted to bring this to attention so that the Architecture Board might clarify the how's and why's of this such that no MP component is implemented in such a way that this becomes a problem for vendors in either direction (by non-OSGi community members equally with OSGi community members)

There are several good recommendations to be made which would both completely satisfy OSGi interop while having zero cost for non-OSGi applications and I would really like if this discussion took place and perhaps a few of these recommendations formalized into Architecture Board recommendations.

Thank you for your consideration.

[smillidge]

A number of MicroProfile implementations have a foundation on OSGI e.g. Payara Server so +1 for ensuring OSGI interoperability.

[rmannibucau]

+1

[rinswind]

+1 for Software AG

We use OSGi as the basis for a number of our products. We'd like to offer MicroProfile to our customers. We're interested in MicroProfile implementations that are fully deployable as peer bundles to the rest of our OSGi infrastructure.

In fact is very desirable that MicroProfile implementations are built on top of the respective standard OSGi services. E.g. JAX-RS whiteboard, HTTP whiteboard, CDI integration, ServiceLoader mediator, ConfigurationAdmin, etc. In this way other OSGi components bound to the standards can enrich MicroProfile runtimes.

[struberg]

+1 for being OSGi friendly.

ofc -1 for a mandatory OSGi requirement if that would ever come up ;)

[tjwatson]

There are several good recommendations to be made which would both completely satisfy OSGi interop while having zero cost for non-OSGi applications and I would really like if this discussion took place and perhaps a few of these recommendations formalized into Architecture Board recommendations.

Do you have examples of the good recommendations? Is there an existing document we should reference that explains the challenges for such interop?

[rotty3000]

Do you have examples of the good recommendations? Is there an existing document we should reference that explains the challenges for such interop?

Hey @tjwatson, I'd expect you know which I was referring to:

1. Where semantic versioning can't be applied, use Portable Java Contracts [1] (avoids nasty arbitrary package version imports)
2. Where the use of ServiceLoader is prescribed, limit the use to ServiceLoader.load(Class) and provide metadata prescribed by the OSGi Service Loader Mediator specification [2].

[1] https://www.osgi.org/portable-java-contract-definitions/
[2] https://osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html

[rotty3000]

Just to be clear, what I'm mostly talking about is adding OSGi metadata to the API jars.

• proper package imports that handle Java EE API (CDI, Inject, Common Annotations, etc.) references gracefully (i.e. Portable Java Contracts)
• use the ServiceLoader in such a way that it's safe for use in both Java Modules AND in OSGi bundles (i.e. Service Loader Mediator)
• avoid static methods in the API who's pretense is to support OSGi

[rotty3000]

As you may have observed I've sent a PR to each of the projects with the necessary changes.

As you can see there is not much to it. I am willing to provide support for these details going forward to all projects as they evolve.

[pavolloffay]

Adding links to PRs

• [osgi] Solutions for https://github.com/eclipse/microprofile/issues/33 microprofile-opentracing#84
• [osgi] Solutions for https://github.com/eclipse/microprofile/issues/33 microprofile-metrics#287
• [osgi] Solutions for https://github.com/eclipse/microprofile/issues/33 microprofile-health#137
• [osgi] Solutions for https://github.com/eclipse/microprofile/issues/33 microprofile-config#381
• [osgi] Solutions for https://github.com/eclipse/microprofile/issues/33 microprofile-fault-tolerance#307
• [osgi] Solutions for https://github.com/eclipse/microprofile/issues/33 microprofile-open-api#265
• [osgi] Solutions for https://github.com/eclipse/microprofile/issues/33 microprofile-jwt-auth#108

[rotty3000]

I'd like to add a note that the OSGi EEG (enterprise expert group) talked over the proposed changes to the ServiceLoader and I believe we have decide we can work around it without any changes to the original code. I will test this out in the coming days. This would lift the need for such changes out of the requirements making it even easier to do the right thing :)

[rotty3000]

furthermore, I will update the PRs to reflect this shortly.

[kaikreuzer]

@rotty3000 Please note that #84 actually conflicts with eclipse/microprofile-metrics#286, so it would be nice if you could take that change also into account.

[rotty3000]

Certainly, I will rebase and make all the corrections shortly.

…

On Fri, Sep 7, 2018 at 8:49 AM, Kai Kreuzer ***@***.***> wrote: @rotty3000 <https://github.com/rotty3000> Please note that #84 actually conflicts with eclipse/microprofile-metrics#286 <eclipse/microprofile-metrics#286>, so it would be nice if you could take that change also into account. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#33 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAI9TIyQ8uPal4MvF6QJTewPTCticBuOks5uYmtagaJpZM4UoP3T> .

-- *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)

[rotty3000]

All the updates are done. I think this is what we'd hope to be the final proposal.

I've struck the limited use of ServiceLoader.load(Class<?>) from the proposal because the OSGi EEG decided that we can solve the issue ourselves avoiding code changes to be needed.

[rotty3000]

To summarize, the proposal is now:

• use Portable Java Contracts for packages (imports) that are not semantically versioned (CDI, Inject, Common Annotations, JAX-RS, etc.)
• apply Service Loader Mediator metadata where ServiceLoader is used

[kenfinnigan]

Closing as "won't do"

[OndroMih]

Worth noting this was decided in the MP Architecture hangout on 26th March 2019: https://docs.google.com/document/d/1uAKRymdAL5Wj1KADzrYKZzSnAFsq74lBfj8lxKQnI6I/edit#

[rinswind]

@OndroMih the document you reference does not give an explanation why proper OSGi metadata won't be supported.
@kenfinnigan Can you provide details?

[kaikreuzer]

I'd be interested in that as well. After the many +1s on this issue and the constructive discussion, it is a bit weird to see the issue closed as "won't do" without any further explanation.

[pilhuhn]

I agree with @kaikreuzer and @rinswind about providing details of the decision (note: I am not questioning the decision itself).

Can we, as followup, now close the linked per-spec issues?

[Emily-Jiang]

Look at the dependency requirement introduced by some PRs such as in Config repo:
Require-Capability:
osgi.contract;
osgi.contract=JavaCDI;
filter:="(&(osgi.contract=JavaCDI)(version=${cdi.api.version}))",\

In Java EE, there is no CDI bundle to provide this capability. With this change, the config bundle will not be able to resolve unless the runtime consumes some OSGi bundles with the JavaCDI capability provided by non-Java EE ecosystem. This restricts the implementation to depend on a particular technology.
In MicroProfile, we focus on what we can provide for end users and leave a lot of freedom for implementations.

[pilhuhn]

Thank you @Emily-Jiang

[rotty3000]

I'm sad I missed the architecture discussion for this. I could have offered a solution that would have solved Emily's concerns while getting OSGi its cake.

Thanks for entertaining it at least.

[kaikreuzer]

I'm sad I missed the architecture discussion for this.

I would have expected that such discussions happen publicly here on the issue as that would be much more in line with the Eclipse principles.

[rotty3000]

I actually brought up this concern previously [1] where I suspected that decisions were being taken during hangouts rather than publicly over lists.

[1] https://groups.google.com/d/msg/microprofile/eCFXGJ_fpac/pxXIA_WtAAAJ

[rinswind]

@Emily-Jiang @rotty3000 So the issue as I understand it is that you can't get an official CDI API packaged as a bundle that provides that contract capability?

[rotty3000]

@rinswind pretty much! A fragment would do it...