[controller-dev] Web Framework Discussion (continued from Kernel Call)
Hi All, 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!). 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 jersey-2.25. Thoughts? Regards, Ryan ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
Re: [controller-dev] Web Framework Discussion (continued from Kernel Call)
For the sake of being open, this [0] is the partial AAA conversion patch, and [1] is needed to test RESTCONF (RESTCONF currently depends on AAA loading the jersey 1.17 runtime dependencies, which isn't correct and should be fixed anyway). Regards, Ryan Goulding [0] https://git.opendaylight.org/gerrit/#/c/70795/ [1] https://git.opendaylight.org/gerrit/#/c/70794/ On Wed, Apr 11, 2018 at 11:50 AM, Ryan Goulding wrote: > Hi All, > > 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!). > > 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 jersey-2.25. > > Thoughts? > > Regards, > > Ryan > ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
Re: [controller-dev] Web Framework Discussion (continued from Kernel Call)
On 11/04/18 17:50, Ryan Goulding wrote: > Hi All, Hello Ryan, > 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 > jersey-2.25. 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. Regards, Robert signature.asc Description: OpenPGP digital signature ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
