New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eureka Client dependency update to Jersey 2.x #600

Closed
cforce opened this Issue Jul 31, 2015 · 21 comments

Comments

Projects
None yet
@cforce

cforce commented Jul 31, 2015

We have to add the spring-boot-starter-jersey to put Jersyey 2.14 on the classpath. The mix of both versions lead to strange NoSuchMethodErrors during application startup! The only solution seems to be to use JAX-RX 1.x (Jersey 1) . This is maybe related to #376

@qiangdavidliu

This comment has been minimized.

Show comment
Hide comment
@qiangdavidliu

qiangdavidliu Jul 31, 2015

Contributor

@cforce eureka-client depends on jersey 1.x only and we have not tested (or guarantee) compatibility with jersey 2.x. We also do not have any plans on upgrading to jersey 2.x in the short term.

Contributor

qiangdavidliu commented Jul 31, 2015

@cforce eureka-client depends on jersey 1.x only and we have not tested (or guarantee) compatibility with jersey 2.x. We also do not have any plans on upgrading to jersey 2.x in the short term.

@foo4u

This comment has been minimized.

Show comment
Hide comment
@foo4u

foo4u Sep 30, 2015

@qiangdavidliu can we shade the dependency on Jersey 1.x? Causing issues since most other frameworks have moved on to JAX-RS 2.0.

foo4u commented Sep 30, 2015

@qiangdavidliu can we shade the dependency on Jersey 1.x? Causing issues since most other frameworks have moved on to JAX-RS 2.0.

@tbak

This comment has been minimized.

Show comment
Hide comment
@tbak

tbak Sep 30, 2015

Contributor

We implement a new transport that will allow one to plug-in different HTTP client implementations. It is still on branch, but we will merge this to master probably next week. Once it is done, you can exclude jersey 1.x, and provide equivalent jersey 2.x implementation
Check: https://github.com/Netflix/eureka/tree/refactorings/transport/eureka-client/src/main/java/com/netflix/discovery/shared/transport

If we have time, we might provide a new module (eureka-client-jersey2), that would do exactly this.

Contributor

tbak commented Sep 30, 2015

We implement a new transport that will allow one to plug-in different HTTP client implementations. It is still on branch, but we will merge this to master probably next week. Once it is done, you can exclude jersey 1.x, and provide equivalent jersey 2.x implementation
Check: https://github.com/Netflix/eureka/tree/refactorings/transport/eureka-client/src/main/java/com/netflix/discovery/shared/transport

If we have time, we might provide a new module (eureka-client-jersey2), that would do exactly this.

@efenderbosch

This comment has been minimized.

Show comment
Hide comment
@efenderbosch

efenderbosch Sep 30, 2015

Would that make it possible to use something other than Jersey? It is just required to be a JAX-RS implementation?

efenderbosch commented Sep 30, 2015

Would that make it possible to use something other than Jersey? It is just required to be a JAX-RS implementation?

@tbak

This comment has been minimized.

Show comment
Hide comment
@tbak

tbak Sep 30, 2015

Contributor

For eureka-client, yes this could be anything that implements EurekaHttpClient API. But on the server side we depend heavily on JAX-RS.

Contributor

tbak commented Sep 30, 2015

For eureka-client, yes this could be anything that implements EurekaHttpClient API. But on the server side we depend heavily on JAX-RS.

@cforce

This comment has been minimized.

Show comment
Hide comment
@cforce

cforce Dec 1, 2015

How its solved now? Do i still need to pimp like this?

 <plugins>
            <plugin>
                <groupId>com.spotify</groupId>
                <artifactId>docker-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <!-- defined in spring-cloud-starter-parent pom (as documentation hint), but needs to be repeated here -->
                <configuration>
                    <requiresUnpack>
                        <dependency>
                            <groupId>com.netflix.eureka</groupId>
                            <artifactId>eureka-core</artifactId>
                        </dependency>
                        <dependency>
                            <groupId>com.netflix.eureka</groupId>
                            <artifactId>eureka-client</artifactId>
                        </dependency>
                    </requiresUnpack>
                </configuration>
            </plugin>
        </plugins>

or

<dependency>
        <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
    <exclusions>                
        <exclusion>
            <artifactId>jsr311-api</artifactId>
            <groupId>javax.ws.rs</groupId>
        </exclusion>
    </exclusions>
</dependency>

cforce commented Dec 1, 2015

How its solved now? Do i still need to pimp like this?

 <plugins>
            <plugin>
                <groupId>com.spotify</groupId>
                <artifactId>docker-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <!-- defined in spring-cloud-starter-parent pom (as documentation hint), but needs to be repeated here -->
                <configuration>
                    <requiresUnpack>
                        <dependency>
                            <groupId>com.netflix.eureka</groupId>
                            <artifactId>eureka-core</artifactId>
                        </dependency>
                        <dependency>
                            <groupId>com.netflix.eureka</groupId>
                            <artifactId>eureka-client</artifactId>
                        </dependency>
                    </requiresUnpack>
                </configuration>
            </plugin>
        </plugins>

or

<dependency>
        <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
    <exclusions>                
        <exclusion>
            <artifactId>jsr311-api</artifactId>
            <groupId>javax.ws.rs</groupId>
        </exclusion>
    </exclusions>
</dependency>
@tbak

This comment has been minimized.

Show comment
Hide comment
@tbak

tbak Dec 1, 2015

Contributor

We are working towards enabling multiple transports in Eureka client. There
is already jersey2 implementation, however DiscoveryClient is still tightly
coupled with jersey1.x. We plan to re-write this code next month, after
holiday season.

On Tue, Dec 1, 2015 at 6:17 AM, Fabi notifications@github.com wrote:

How its solved now? Do i still need to pimp like this?

com.spotify
docker-maven-plugin

org.springframework.boot
spring-boot-maven-plugin

com.netflix.eureka
eureka-core

com.netflix.eureka
eureka-client

or

org.springframework.cloud
spring-cloud-starter-eureka

jsr311-api
javax.ws.rs


Reply to this email directly or view it on GitHub
#600 (comment).

Contributor

tbak commented Dec 1, 2015

We are working towards enabling multiple transports in Eureka client. There
is already jersey2 implementation, however DiscoveryClient is still tightly
coupled with jersey1.x. We plan to re-write this code next month, after
holiday season.

On Tue, Dec 1, 2015 at 6:17 AM, Fabi notifications@github.com wrote:

How its solved now? Do i still need to pimp like this?

com.spotify
docker-maven-plugin

org.springframework.boot
spring-boot-maven-plugin

com.netflix.eureka
eureka-core

com.netflix.eureka
eureka-client

or

org.springframework.cloud
spring-cloud-starter-eureka

jsr311-api
javax.ws.rs


Reply to this email directly or view it on GitHub
#600 (comment).

@singerdmx

This comment has been minimized.

Show comment
Hide comment
@singerdmx

singerdmx Jan 21, 2016

Any updates on Jersey2 version? Thanks!

singerdmx commented Jan 21, 2016

Any updates on Jersey2 version? Thanks!

@qiangdavidliu

This comment has been minimized.

Show comment
Hide comment
@qiangdavidliu

qiangdavidliu Jan 21, 2016

Contributor

@singerdmx we are doing some work that will help with this this quarter, but we can't commit to any timelines right now unfortunately. I will update once we have anything more concrete.

Contributor

qiangdavidliu commented Jan 21, 2016

@singerdmx we are doing some work that will help with this this quarter, but we can't commit to any timelines right now unfortunately. I will update once we have anything more concrete.

@oembedler

This comment has been minimized.

Show comment
Hide comment
@oembedler

oembedler Feb 19, 2016

Could someone give rough estimate on how long it takes to decouple code from jersey v1?
Thanks!

oembedler commented Feb 19, 2016

Could someone give rough estimate on how long it takes to decouple code from jersey v1?
Thanks!

@jasollien

This comment has been minimized.

Show comment
Hide comment
@jasollien

jasollien Apr 6, 2016

Hi guys. Uncopling of jersey1 is essential for us in order to use Eureka. Any update on the progress would be much appreciated.

jasollien commented Apr 6, 2016

Hi guys. Uncopling of jersey1 is essential for us in order to use Eureka. Any update on the progress would be much appreciated.

@spencergibb

This comment has been minimized.

Show comment
Hide comment
@spencergibb

spencergibb Apr 6, 2016

Contributor

It's not a priority for them, but I'm sure they would look at a pull request.

Contributor

spencergibb commented Apr 6, 2016

It's not a priority for them, but I'm sure they would look at a pull request.

@saneItchyHog

This comment has been minimized.

Show comment
Hide comment
@saneItchyHog

saneItchyHog Apr 7, 2016

Eagerly awaiting this as well

saneItchyHog commented Apr 7, 2016

Eagerly awaiting this as well

@qiangdavidliu

This comment has been minimized.

Show comment
Hide comment
@qiangdavidliu

qiangdavidliu Apr 7, 2016

Contributor

@jasollien @saneItchyHog we are taking a more drastic direction w.r.t. the client side of eureka (thinner clients with no jersey dependencies at all), and is working more towards this goal at the moment. We believe that this is a more flexible solution at the end of the day as it addresses other dependency problems as well as the jersey issue.

Us providing a jersey 2.x implementation of the current client is technically feasible, however part of the value of eureka (client and server) is that is it battle tested in very large and varied deployment scenarios at Netflix, and even if we provide a jersey 2.x variant, it will not be used internally and will lack similar levels of production readiness.

Having said the above, the aforementioned (earlier in this thread) new transport is now active, and there is a jersey 2.x skeleton in the eureka-client-jersey2 submodule, so we are definitely more than willing to look at any pull requests to build on top of these.

Contributor

qiangdavidliu commented Apr 7, 2016

@jasollien @saneItchyHog we are taking a more drastic direction w.r.t. the client side of eureka (thinner clients with no jersey dependencies at all), and is working more towards this goal at the moment. We believe that this is a more flexible solution at the end of the day as it addresses other dependency problems as well as the jersey issue.

Us providing a jersey 2.x implementation of the current client is technically feasible, however part of the value of eureka (client and server) is that is it battle tested in very large and varied deployment scenarios at Netflix, and even if we provide a jersey 2.x variant, it will not be used internally and will lack similar levels of production readiness.

Having said the above, the aforementioned (earlier in this thread) new transport is now active, and there is a jersey 2.x skeleton in the eureka-client-jersey2 submodule, so we are definitely more than willing to look at any pull requests to build on top of these.

@nick-pww

This comment has been minimized.

Show comment
Hide comment
@nick-pww

nick-pww Apr 7, 2016

@qiangdavidliu I think most of the folks following this would agree that removing the Jersey dependency from your side of things would be the 'best' solution for folks who are using this library. Personally, I don't care what you use for your underlying communications as long it's been well tested and vetted (which is what you are going for), AND doesn't get in the way of our own application development (which Jersey dependencies of any kind have the chance of doing).

tl;dr: 👍

Look forward to the changes!

nick-pww commented Apr 7, 2016

@qiangdavidliu I think most of the folks following this would agree that removing the Jersey dependency from your side of things would be the 'best' solution for folks who are using this library. Personally, I don't care what you use for your underlying communications as long it's been well tested and vetted (which is what you are going for), AND doesn't get in the way of our own application development (which Jersey dependencies of any kind have the chance of doing).

tl;dr: 👍

Look forward to the changes!

@mattnelson

This comment has been minimized.

Show comment
Hide comment
@mattnelson

mattnelson Jun 30, 2016

Contributor

@qiangdavidliu

we are taking a more drastic direction w.r.t. the client side of eureka (thinner clients with no jersey dependencies at all), and is working more towards this goal at the moment.

I am starting to look into eureka-client-jersey2 and picking up where you guys left off, but I wanted to put a feeler out to see what progress had been made on the jersey-agnostic client and if there was the possibility of a release candidate being available.

Contributor

mattnelson commented Jun 30, 2016

@qiangdavidliu

we are taking a more drastic direction w.r.t. the client side of eureka (thinner clients with no jersey dependencies at all), and is working more towards this goal at the moment.

I am starting to look into eureka-client-jersey2 and picking up where you guys left off, but I wanted to put a feeler out to see what progress had been made on the jersey-agnostic client and if there was the possibility of a release candidate being available.

@qiangdavidliu

This comment has been minimized.

Show comment
Hide comment
@qiangdavidliu

qiangdavidliu Jun 30, 2016

Contributor

@mattnelson as part of the new work we are doing a bit more than just a different client, but are also taking advantage of this to rework the data model to update it to the 2016 requirements we have as a company, compared to when eureka was first published (better VPC support for example). Part of the work will include introducing a proxy tier to handle the compatibility with the existing eureka server so I suspect it would not fit with your immediate use case.

If you are keen to follow up on the existing -jersey2 work that would be greatly appreciated, as I don't think the newer work will completely deprecate all use of the existing client(s). I think it will bring a lot of value to this project.

Thanks.

Contributor

qiangdavidliu commented Jun 30, 2016

@mattnelson as part of the new work we are doing a bit more than just a different client, but are also taking advantage of this to rework the data model to update it to the 2016 requirements we have as a company, compared to when eureka was first published (better VPC support for example). Part of the work will include introducing a proxy tier to handle the compatibility with the existing eureka server so I suspect it would not fit with your immediate use case.

If you are keen to follow up on the existing -jersey2 work that would be greatly appreciated, as I don't think the newer work will completely deprecate all use of the existing client(s). I think it will bring a lot of value to this project.

Thanks.

@spencergibb

This comment has been minimized.

Show comment
Hide comment
@spencergibb

spencergibb Jun 30, 2016

Contributor

@mattnelson we have users (large institutions) that would love have a jersey2 client working.

Contributor

spencergibb commented Jun 30, 2016

@mattnelson we have users (large institutions) that would love have a jersey2 client working.

@mattnelson

This comment has been minimized.

Show comment
Hide comment
@mattnelson

mattnelson Jul 20, 2016

Contributor

Got the PR out for this on #821

Contributor

mattnelson commented Jul 20, 2016

Got the PR out for this on #821

@adoura

This comment has been minimized.

Show comment
Hide comment
@adoura

adoura Oct 25, 2016

@spencergibb now jersey 2 compatibility released in eureka 1.6.0 but you planning to upgrade to eureka 1.5.6 in 1.3.0.M1.
is there possibility to push upgrades to 1.6.0 ?

adoura commented Oct 25, 2016

@spencergibb now jersey 2 compatibility released in eureka 1.6.0 but you planning to upgrade to eureka 1.5.6 in 1.3.0.M1.
is there possibility to push upgrades to 1.6.0 ?

@nmadzharov

This comment has been minimized.

Show comment
Hide comment
@nmadzharov

nmadzharov Nov 30, 2017

Considering it has been over a year since the issue was closed and nowadays spring-boot applications with jersey 2 clients are widely-used, what is the recommended approach to use Eureka client in web services which also already use jersey 2 clients?

For instance, I have struggled to find a recommendation or example on using eureka clients with any spring boot app that utilizes spring-boot-starter-jersey or the likes (jersey 2 dependencies) which are included in most spring examples.

nmadzharov commented Nov 30, 2017

Considering it has been over a year since the issue was closed and nowadays spring-boot applications with jersey 2 clients are widely-used, what is the recommended approach to use Eureka client in web services which also already use jersey 2 clients?

For instance, I have struggled to find a recommendation or example on using eureka clients with any spring boot app that utilizes spring-boot-starter-jersey or the likes (jersey 2 dependencies) which are included in most spring examples.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment