#30, Jersey 2.26 support on 2.x

[pierre-l]

Here is a proposal for the upgrade to Jersey 2.26.
This requires a JAX-RS upgrade, which implies a Resteasy upgrade too.

The JAX-RS upgrade breaks the classloader injection hack in the ContainerRule. I replaced it using a temporary file. Any suggestion or would be welcome.

Once reviewed and approved, I intend to apply this to the master branch too.

[victornoel]

thank @pierre-l, I will take a look at it this week-end.

The question of bumping to jersey 2.26 is complex, in particular because it will break compatibility with stable dropwizard, but we can try to tackle it.

[pierre-l]

Hi @victornoel, thank you for this quick answer.
It seems to me that this compatibility issue would be solved using a multimodule project:

• core
• test-tools
• jersey225
• jersey226
• resteasy

This would also reduce future classpath issues. You may want it to be done before the Jersey upgrade though.

[victornoel]

@pierre-l yes, I agree, I have been thinking about that for a while (in particular for the tests) and your PR is making me wonder about the best way to handle the transition for jax-rs-pac4j 2.x... I wouldn't want to break backward compatibility, but maybe if we combine a multi-module project + a legacy jax-rs-pac4j artifact that just bring everything together (except for the container specific dependencies), this could work.

[victornoel]

by the way, @pierre-l, if you have feedbacks on things to change in jax-rs-pac4j that break backward compatibility, don't hesitate to open issues before 3.x is released (I suppose it should happen in not so long...) :)

[pierre-l]

maybe if we combine a multi-module project + a legacy jax-rs-pac4j artifact that just bring everything together (except for the container specific dependencies), this could work.

Do you mean having a sixth module, the "legacy" one, only on 2.x, containing the current mix of dependencies?

if you have feedbacks on things to change in jax-rs-pac4j that break backward compatibility

I haven't yet, but to be honest I haven't looked for it. I'll keep this in mind ;)

[victornoel]

Do you mean having a sixth module, the "legacy" one, only on 2.x, containing the current mix of dependencies?

Exactly, I did some tests and it should work :)

[leleuj]

ETA for pac4j v3.0.0: early May

[victornoel]

@pierre-l the new module organisation is merged in master and 2.x, could you rebase this branch over it?

I feel like we should do the following (it's open to discussion):

• for 2.x, we should introduce a jersey226-pac4j module, so that jersey-pac4j is backward compatible until pac4j 3.0 is released. After that, we won't touch so much 2.x I think so it will stay like this.
• for master, we should move the current jersey-pac4j to jersey225-pac4j and start supporting jersey 2.26 in jersey-pac4j. Don't forget to change the dependency in dropwizard-pac4j to jersey225-pac4j then. With time jersey225-pac4j will disappear I think.

Concerning jax-rs: even though 2.1 is different, it is backward compatible with 2.0.1 I suppose (is it?), so for now, I feel like we only need jax-rs 2.0.1 APIs, so the core module can continue to relies on jax-rs 2.0.1 and all the integrations should provide at least 2.0.1 compatibility but can add new things for 2.1 (not sure the need exists though right now).

Concerning Resteasy, if there is a concrete API change that motivates to also change our code for latest version of resteasy, then let's do it in another PR maybe, and following the same strategy as with jersey then.

What do you think @leleuj and @pierre-l?

[pierre-l]

@victornoel Seems good to me. I have the same feeling about JAX-RS.

[pierre-l]

Closing in favor of #40, #41