-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-12154] Upgrade to Jersey 2 #12715
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
Conversation
Changes to the Spark Web UI code were required to compile. The changes were relatively standard Jersey migration things.
|
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it problematic to have both javax.inject-1 and javax.inject-2.4.0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
Test build #57039 has finished for PR 12715 at commit
|
yarn/pom.xml
Outdated
| <dependency> | ||
| <groupId>com.sun.jersey</groupId> | ||
| <artifactId>jersey-core</artifactId> | ||
| <groupId>org.glassfish.jersey.core</groupId> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
Test build #57041 has finished for PR 12715 at commit
|
|
Test build #57069 has finished for PR 12715 at commit
|
|
Test build #57067 has finished for PR 12715 at commit
|
|
retest this please |
|
Test build #57070 has finished for PR 12715 at commit
|
|
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
@JoshRosen I did not change the Jersey dependency for the docker-integration-tests project. Should we change that here or leave it alone? |
|
Jenkins, retest this please |
|
Test build #57155 has finished for PR 12715 at commit
|
|
Test build #57174 has finished for PR 12715 at commit
|
|
Test build #57177 has finished for PR 12715 at commit
|
|
Test build #57182 has finished for PR 12715 at commit
|
|
Hm... Are SparkLauncher tests just flaky or could this change have directly affected that? |
|
Jenkins, retest this please |
|
That particular one shouldn't be affected by these changes. I'll take a closer look at it separately. |
|
Test build #57184 has finished for PR 12715 at commit
|
|
Test build #57196 has finished for PR 12715 at commit
|
|
LGTM, I'll leave this for @srowen since he had a comment about licenses. |
|
Yeah you can update the following section of |
yarn/pom.xml
Outdated
| <groupId>com.sun.jersey</groupId> | ||
| <artifactId>jersey-core</artifactId> | ||
| <scope>test</scope> | ||
| <version>1.9</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
@srowen Should the NOTICE still contain Jersey 1 since I think we still pull it in explicitly for YARN unit tests? |
|
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. |
|
Test build #57622 has finished for PR 12715 at commit
|
|
I didn't see any old-Jersey jars in the lib directory. |
|
@srowen given that Jersey 1 isn't being distributed, this PR should be good to go? |
|
LGTM; let me leave this open a short while longer for comments. |
|
Question: will this be ported to the 1.6 branch? |
|
No, it's too significant a change for a maintenance release. |
|
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? |
|
I think the best option is to shade Jersey if you need a different version. |
|
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 <[email protected]> Closes #12715 from mccheah/feature/upgrade-jersey. (cherry picked from commit b7fdc23) Signed-off-by: Sean Owen <[email protected]>
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.