Make sdk OSGi friendly or convert it to an OSGi bundle

[pizerg]

Re-opening a previous issue that was closed as considered "obsolete" for some reason.

[jianghaolu]

@pizerg Could you point us to the original issue please?

[pizerg]

#410

[jianghaolu]

@pizerg Sorry I don't have the context back in 2013 but if I'm understanding correctly, in order to have OSGi work correctly, a way other than loading from ServiceLoader should be implemented.

The good news is that we are adding public constructors to the rest clients and deprecating the service loader and configuration stuff so that alternative ways will be provided to initialize the clients. The bad news is that we don't have a ETA on this yet. It's not included in the upcoming release.

I saw you had a dirty workaround by now. I'm afraid it needs be kept like that for a few more months. Please let me know if you have other concerns.

Thanks.
Jianghao

[pizerg]

@ljhljh235 The idea (besides deprecating ServiceLoader) would be to offer the SDK as an OSGi Bundle instead of a regular java bundle so it could be automatically deployed in any OSGi environment. I don't think it's a big effort to convert a regular bundle to an OSGi bundle so maybe it can be done soon. Will keep using our workaround meanwhile.

Thanks,

Adrián Cañadas

[hovsepm]

@pizerg

Thank you for the comments. We are in the process of redesigning Java SDK for Azure. In the new approach we will not use ServiceLoader anymore. We will consider your feedbacks about OSGI for the future version if applicable but for the current version this will not be fixed as it does not meet the bar.

Thanks!

[sarod]

@hovsep it looks like current versions of Azure SDK is still using service loader and is still not OSGI compatible
Should this issue be re-opened?

[sarod]

We had an issue running in OSGI env with HttpClientProviders not able to find the provider in classpath even though azure-core-httpnetty was present.
The app to fail with an error message like this

A request was made to load the default HttpClient provider but one could not be found on the classpath. If you are using a dependency manager, consider including a dependency on azure-core-http-netty or azure-core-http-okhttp. Depending on your existing dependencies, you have the choice of Netty or OkHttp implementations. Additionally, refer to https://aka.ms/azsdk/java/docs/custom-httpclient to learn about writing your own implementation.

We solved the issue by modifying manifest files (META-INF/MANIFEST.MF) for azure-core & azure-core-http-netty to use Service Loader Mediator (https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html)

In our case we used the following instructions for p2-maven-plugin:

<dependency>
    <id>com.azure:azure-core:1.11.0</id>
    <source>true</source>
    <transitive>false</transitive>
    <instructions>
        <Require-Capability>osgi.extender; filter:="(osgi.extender=osgi.serviceloader.processor)",
            osgi.serviceloader; filter:="(osgi.serviceloader=com.azure.core.http.HttpClientProvider)"; cardinality:=multiple</Require-Capability>
    </instructions>
</dependency>
<dependency>
    <id>com.azure:azure-core-http-netty:1.7.0</id>
    <source>true</source>
    <transitive>true</transitive>
    <instructions>
        <Require-Capability>osgi.extender; filter:="(osgi.extender=osgi.serviceloader.registrar)"</Require-Capability>
        <Provide-Capability>osgi.serviceloader; osgi.serviceloader=com.azure.core.http.HttpClientProvider</Provide-Capability>
    </instructions>
</dependency>

[pabasara-mahindapala]

We had an issue running in OSGI env with HttpClientProviders not able to find the provider in classpath even though azure-core-httpnetty was present. The app to fail with an error message like this

A request was made to load the default HttpClient provider but one could not be found on the classpath. If you are using a dependency manager, consider including a dependency on azure-core-http-netty or azure-core-http-okhttp. Depending on your existing dependencies, you have the choice of Netty or OkHttp implementations. Additionally, refer to https://aka.ms/azsdk/java/docs/custom-httpclient to learn about writing your own implementation.

We solved the issue by modifying manifest files (META-INF/MANIFEST.MF) for azure-core & azure-core-http-netty to use Service Loader Mediator (https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html)

In our case we used the following instructions for p2-maven-plugin:

<dependency>
    <id>com.azure:azure-core:1.11.0</id>
    <source>true</source>
    <transitive>false</transitive>
    <instructions>
        <Require-Capability>osgi.extender; filter:="(osgi.extender=osgi.serviceloader.processor)",
            osgi.serviceloader; filter:="(osgi.serviceloader=com.azure.core.http.HttpClientProvider)"; cardinality:=multiple</Require-Capability>
    </instructions>
</dependency>
<dependency>
    <id>com.azure:azure-core-http-netty:1.7.0</id>
    <source>true</source>
    <transitive>true</transitive>
    <instructions>
        <Require-Capability>osgi.extender; filter:="(osgi.extender=osgi.serviceloader.registrar)"</Require-Capability>
        <Provide-Capability>osgi.serviceloader; osgi.serviceloader=com.azure.core.http.HttpClientProvider</Provide-Capability>
    </instructions>
</dependency>

Thanks. This solved the issue when used with Apache Aries SPI Fly