Uh oh!
There was an error while loading. Please reload this page.
[SPARK-12154] Upgrade to Jersey 2 - #12715
Conversation
Changes to the Spark Web UI code were required to compile. The changes were relatively standard Jersey migration things.
SparkQA
commented
Apr 26, 2016
Test build #57035 has finished for PR 12715 at commit
|
| javassist-3.18.1-GA.jar | ||
| javax.annotation-api-1.2.jar | ||
| javax.inject-1.jar | ||
| javax.inject-2.4.0-b34.jar |
There was a problem hiding this comment.
Is it problematic to have both javax.inject-1 and javax.inject-2.4.0?
There was a problem hiding this comment.
I wouldn't say problematic, but both provide the exact same set of classes, so it's at least redundant. Being a javax API, I at least assume the newer one is backwards compatible.
SparkQA
commented
Apr 26, 2016
Test build #57039 has finished for PR 12715 at commit
|
| <dependency> | ||
| <groupId>com.sun.jersey</groupId> | ||
| <artifactId>jersey-core</artifactId> | ||
| <groupId>org.glassfish.jersey.core</groupId> |
There was a problem hiding this comment.
Actually this doesn't work because the Mini YARN cluster needs Jersey 1 to start up. Since this is only in test scope we should be fine to keep the Jersey 1 dependency here - I'll add a comment to clarify that.
SparkQA
commented
Apr 27, 2016
Test build #57041 has finished for PR 12715 at commit
|
SparkQA
commented
Apr 27, 2016
Test build #57069 has finished for PR 12715 at commit
|
SparkQA
commented
Apr 27, 2016
Test build #57067 has finished for PR 12715 at commit
|
vanzin
commented
Apr 27, 2016
retest this please |
SparkQA
commented
Apr 27, 2016
Test build #57070 has finished for PR 12715 at commit
|
SparkQA
commented
Apr 27, 2016
Test build #57082 has finished for PR 12715 at commit
|
| antlr-runtime-3.4.jar | ||
| antlr4-runtime-4.5.2-1.jar | ||
| aopalliance-1.0.jar | ||
| aopalliance-repackaged-2.4.0-b34.jar |
There was a problem hiding this comment.
We'll probably have to look at the impact on the LICENSE file for all these dependency changes. I can help do that bit if once we're pretty sure this will work.
mccheah
commented
Apr 27, 2016
@JoshRosen I did not change the Jersey dependency for the docker-integration-tests project. Should we change that here or leave it alone? |
mccheah
commented
Apr 27, 2016
Jenkins, retest this please |
SparkQA
commented
Apr 27, 2016
Test build #57155 has finished for PR 12715 at commit
|
SparkQA
commented
Apr 27, 2016
Test build #57174 has finished for PR 12715 at commit
|
SparkQA
commented
Apr 27, 2016
Test build #57177 has finished for PR 12715 at commit
|
SparkQA
commented
Apr 28, 2016
Test build #57182 has finished for PR 12715 at commit
|
mccheah
commented
Apr 28, 2016
Hm... Are SparkLauncher tests just flaky or could this change have directly affected that? |
mccheah
commented
Apr 28, 2016
Jenkins, retest this please |
vanzin
commented
Apr 28, 2016
That particular one shouldn't be affected by these changes. I'll take a closer look at it separately. |
SparkQA
commented
Apr 28, 2016
Test build #57184 has finished for PR 12715 at commit
|
SparkQA
commented
Apr 28, 2016
Test build #57196 has finished for PR 12715 at commit
|
vanzin
commented
Apr 28, 2016
LGTM, I'll leave this for @srowen since he had a comment about licenses. |
srowen
commented
Apr 29, 2016
Yeah you can update the following section of |
| <groupId>com.sun.jersey</groupId> | ||
| <artifactId>jersey-core</artifactId> | ||
| <scope>test</scope> | ||
| <version>1.9</version> |
There was a problem hiding this comment.
One last finishing touch .. you could define (in just this pom) a property for Jersey 1.x versions to make sure they're modified together.
mccheah
commented
May 3, 2016
@srowen Should the NOTICE still contain Jersey 1 since I think we still pull it in explicitly for YARN unit tests? |
srowen
commented
May 3, 2016
This is looking good. Regarding the license, it depends on whether the artifacts we distribute contain Jersey 1.x or not. I have the impression it isn't at the moment. If you have the build handy and can look at the assembly and grep its contents, that would help verify whether 1.x classes are still there or not. If not, this is fine. Otherwise just restore the Jersey 1.x license statements. |
SparkQA
commented
May 3, 2016
Test build #57622 has finished for PR 12715 at commit
|
mccheah
commented
May 3, 2016
I didn't see any old-Jersey jars in the lib directory. |
mccheah
commented
May 4, 2016
@srowen given that Jersey 1 isn't being distributed, this PR should be good to go? |
srowen
commented
May 4, 2016
LGTM; let me leave this open a short while longer for comments. |
fabriziocucci
commented
May 4, 2016
Question: will this be ported to the 1.6 branch? |
srowen
commented
May 4, 2016
No, it's too significant a change for a maintenance release. |
fabriziocucci
commented
May 4, 2016
Thanks Sean. So, just to recap regarding this, whoever is stuck trying to use spark in a web application based on Jersey 2 has currently the following options:
Is my understanding correct? |
srowen
commented
May 4, 2016
I think the best option is to shade Jersey if you need a different version. |
srowen
commented
May 5, 2016
Merged to master/2.0 |
## What changes were proposed in this pull request? Replace com.sun.jersey with org.glassfish.jersey. Changes to the Spark Web UI code were required to compile. The changes were relatively standard Jersey migration things. ## How was this patch tested? I did a manual test for the standalone web APIs. Although I didn't test the functionality of the security filter itself, the code that changed non-trivially is how we actually register the filter. I attached a debugger to the Spark master and verified that the SecurityFilter code is indeed invoked upon hitting /api/v1/applications. Author: mcheah <mcheah@palantir.com> Closes#12715 from mccheah/feature/upgrade-jersey. (cherry picked from commit b7fdc23) Signed-off-by: Sean Owen <sowen@cloudera.com>
What changes were proposed in this pull request?
Replace com.sun.jersey with org.glassfish.jersey. Changes to the Spark Web UI code were required to compile. The changes were relatively standard Jersey migration things.
How was this patch tested?
I did a manual test for the standalone web APIs. Although I didn't test the functionality of the security filter itself, the code that changed non-trivially is how we actually register the filter. I attached a debugger to the Spark master and verified that the SecurityFilter code is indeed invoked upon hitting /api/v1/applications.