Helidon MP 2.3.0 does not follow Microprofile 3.3 standard

[gtenham]

Environment Details

• Helidon Version: 2.3.0
• Helidon MP
• JDK version: 11.0.7
• OS: Windows/Linux
• Docker version (if applicable): NA

---

Problem Description

Helidon MP 2.3.0 introduced a dependency upgrade of Jersey en MP RestClient 2.0 (see #2971) which makes this release partly following the MicroProfile 4.0 standard.

When coding against the MicroProfile standard 3.3 using the corresponding MP RestClient, it is not possible to upgrade Helidon MP 2.2.2 to Helidon MP 2.3.0 while keeping our code compatible with MicroProfile 3.3 standard.

Which Helidon MP release is scheduled to implement the MicroProfile 4.0 standard completely?

[spericas]

When coding against the MicroProfile standard 3.3 using the corresponding MP RestClient, it is not possible to upgrade Helidon MP 2.2.2 to Helidon MP 2.3.0 while keeping our code compatible with MicroProfile 3.3 standard.

What exactly makes it impossible to upgrade your app?

[gtenham]

When coding against the MicroProfile standard 3.3 using the corresponding MP RestClient, it is not possible to upgrade Helidon MP 2.2.2 to Helidon MP 2.3.0 while keeping our code compatible with MicroProfile 3.3 standard.

What exactly makes it impossible to upgrade your app?

We do not develop our application for Helidon MP (use Helidon as a runtime only) but compile our code against the MicroProfile 3.3 interfaces. In our code we are using the RestClient API interfaces coming with MicroProfile 3.3, which turned to be incompatible with the RestClient implementation coming with Helidon 2.3.0.

It seems Heldion 2.3.0 is still implementing the MicroProfile 3.3 version, except for the MP RestClient API 2.0 which is part of the MicroProfile 4.0 standard (Implementation within Helidon 2.3.0 is from Jersey, i guess?)

I hope that i was able to clearify our setup.

[spericas]

@gtenham Yes, Jersey 2.34 is bringing support for RestClient 2.0. With some pom gymnastics, there should be way to downgrade the API and the Jersey module that implements RestClient. I just tried it out in some basic app: the general idea is to exclude the new and include the old.

First exclude new deps from Helidon bundle, or wherever they are pulled from in your pom as reported by mvn dependency:tree:

       <dependency>
            <groupId>io.helidon.microprofile.bundles</groupId>
            <artifactId>helidon-microprofile</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.glassfish.jersey.ext.microprofile</groupId>
                    <artifactId>jersey-mp-rest-client</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

Next include the old API and Jersey jars as follows:

        <dependency>
            <groupId>org.glassfish.jersey.ext.microprofile</groupId>
            <artifactId>jersey-mp-rest-client</artifactId>
            <version>2.33</version>
            <exclusions>
                <exclusion>
                    <groupId>jakarta.enterprise</groupId>
                    <artifactId>jakarta.enterprise.cdi-api</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>javax.enterprise</groupId>
                    <artifactId>cdi-api</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.eclipse.microprofile.rest.client</groupId>
            <artifactId>microprofile-rest-client-api</artifactId>
            <version>1.4.1</version>
        </dependency>

Note that the deps above refer to Jersey 2.33 instead of 2.34 and revert the RestClient API to the previous version. Let me know how it goes.

[gtenham]

@gtenham Yes, Jersey 2.34 is bringing support for RestClient 2.0. With some pom gymnastics, there should be way to downgrade the API and the Jersey module that implements RestClient. I just tried it out in some basic app: the general idea is to exclude the new and include the old.

First exclude new deps from Helidon bundle, or wherever they are pulled from in your pom as reported by mvn dependency:tree:

       <dependency>
            <groupId>io.helidon.microprofile.bundles</groupId>
            <artifactId>helidon-microprofile</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.glassfish.jersey.ext.microprofile</groupId>
                    <artifactId>jersey-mp-rest-client</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

Next include the old API and Jersey jars as follows:

        <dependency>
            <groupId>org.glassfish.jersey.ext.microprofile</groupId>
            <artifactId>jersey-mp-rest-client</artifactId>
            <version>2.33</version>
            <exclusions>
                <exclusion>
                    <groupId>jakarta.enterprise</groupId>
                    <artifactId>jakarta.enterprise.cdi-api</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>javax.enterprise</groupId>
                    <artifactId>cdi-api</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.eclipse.microprofile.rest.client</groupId>
            <artifactId>microprofile-rest-client-api</artifactId>
            <version>1.4.1</version>
        </dependency>

Note that the deps above refer to Jersey 2.33 instead of 2.34 and revert the RestClient API to the previous version. Let me know how it goes.

We are using the helidon-core bundle so only need to change the rest-client dependency part.
Works for me.

Waiting anxious for Helidon supporting MP 4.

Thanks.

[tomas-langer]

Could you please check if your MP specifications are defined in compile or provided scope in your application?
If you compile against them and the use helidon bundle, it should be sufficient to change the scope to provided for MP Rest client.
The API has not changed, so there should be not problem changing the dependency.

If this does not help, would you kindly share the stacktrace you get?

Thanks a lot,
Tomas

[gtenham]

@tomas-langer

Added mvn dependency-tree and runtime stacktrace after changing Helidon to version 2.3.0 with MicroProfile 3.3 in attachment.

MP Restclient scope changed to provided. Still not able to run the application

Gerton

helidon-bugreport.zip

[spericas]

@gtenham The dependencies file in your zip file is empty. Could you provide that and possibly your pom? I got the runtime error from the other file.

[gtenham]

@spericas mvn-dependencies.txt

[spericas]

@gtenham Thanks, it would really help if you can attach your pom as well. It would help me understand some things in the deps file. Otherwise, if you can't share, we should consider creating a sample app that shows the problem.

[gtenham]

@spericas Uploaded a sample multi-module project with a pom-file setup which look like our project setup.

parent pom contains the versions for MicroProfile and Helidon
service-a module contains a basic jaxrs service with one endpoint http://localhost:8080/service-a/ping
service-b module contains a restclient to service-a called through http://localhost:8081/service-b/ping

When calling service-b endpoint an error occurs from the rest client which is different than the one uploaded before (probably due to some additional code not in this sample)!
When changing the scope to provided for microprofile-rest-client-api in service-b pom-file the service-b does not start and provides the error uploaded before.

When changing helidon.version property to 2.2.2 everything works fine also when changing the service-b pom-file using the workaround provided (change jersy-rest-client to 2.33) combined with helidon 2.3.0 it also works fine.

I hope this helps you investigating the problem

sample-project.zip

[spericas]

@gtenham Made a few changes to your sample to produce executable jars and was able to reproduce the problem.

Caused by: java.lang.NoSuchMethodError: 'org.eclipse.microprofile.rest.client.RestClientBuilder org.eclipse.microprofile.rest.client.RestClientBuilder.followRedirects(boolean)'
	at org.glassfish.jersey.microprofile.restclient.RestClientProducer.create(RestClientProducer.java:142)
	at org.jboss.weld.contexts.unbound.DependentContextImpl.get(DependentContextImpl.java:64)
	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:694)
	at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:794)
	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)

This is because Jersey is calling a 2.0 API method. So, in summary, if you force the classpath to include Rest Client 1.4, then you'll run into this error. But from the point of view of the application, there is no incompatibility: your application should run without changes provided the classpath is setup properly. If it is required for you to use Rest Client 1.4, then you'd need to downgrade Jersey's module as discussed above.

[gtenham]

@spericas Thanks for the update.

Rest Client 1.4 is part of MicroProfile 3.3 and Rest Client 2.0 is part of MicroProfile 4, which means my issue is valid that Helidon MP 2.3.0 is not fully compatible with MicroProfile 3.3 nor MicroProfile 4.0.

This means i have to downgrade Jersey Rest Client to stay updated with Helidon 2 MP as a MicroProfile implementation or change implementation.

[spericas]

Reopening so we can provide some documentation about this.

[spericas]

@gtenham I'm not saying it is invalid, just that there's an easy workaround. For example, in your sample project, if you swap the imports on your main pom.xml, you should get the 2.0 jar.

We are currently discussing using reflection in Jersey to remain fully compatible with the 1.4 jar. Will keep you posted.

[spericas]

Jersey's PR eclipse-ee4j/jersey#4835

[spericas]

@gtenham This issue is now targeted for 2.4.0. Stay tuned.

[spericas]

Integration with Jersey 2.35 is now complete. This incompatibility issue will be resolved in Helidon 2.4.0.