On 11/04/18 17:50, Ryan Goulding wrote:
During the Kernel call this past Tuesday, we talked about attempting an
isolated transition of AAA restful web services from Jersey 1 to Jersey
2. I attempted this change yesterday, and was able to partially convert
(I just temporarily removed non-essential code that would've required
overhaul). However, when I compiled NETCONF next to test RESTCONF, I
quickly realized that:
1) jersey-2.26 won't behave well, since it relies on javax.ws.rs-api 2.1
and jersey 1.17 relies on javax.ws.rs-api 2.0.1. This leads to a Uses
constraint violation since the dependency is provided via two chains
(and two different versions too!).
Well, that upgrade has to wait for Neon then -- we simply cannot take
much more churn this low in the project.
2) jersey-2.25 won't work for a similar reason. Even though it relies
on the older javax.ws.rs-api 2.0.1 which is currently in place, jersey
1.17 repackages javax.ws.rs-api. This means that utilizing the off the
shelf javax.ws.rs-api 2.0.1 causes another Uses constraint violation,
since the dependency is provided via upstream properly and jersey 1.17
in a repackaged form.
I am starting to really agree with the sentiment that we should just
stick to only one implementation across the board. Additionally, I
believe that isolating this in an API (utility or not) will help the
transition since there will be a single point to toggle the
implementations. We may want to also discuss the drawbacks of jersey
2. Namely, it appears to require a ton of overhead dependencies and
starts a bit slower in newer versions. Maybe that is fine, but we
should fully understand the tradeoffs before investing more time. We
should also settle on what the intended version should be for jersey 2
if we go that route, since jersey-2.26 is a lot different than even
Agreed, Tom's utility approach is probably the most sensible one. I took
a very simple stab at that with https://git.opendaylight.org/gerrit/70919
I do belive using this you can eliminate any and all references to
jersey in shiro-impl.