[HBASE-25844] Fix Jersey for hbase-server processes

• Type: Task
• Status: Reopened
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 3.0.0-alpha-1, 2.5.0
• Component/s: master, regionserver, thirdparty
• Assignee: Nick Dimiduk
• Reporter: Nick Dimiduk
• Created: 03/May/21 23:12
• Updated: 02/May/23 10:05

Description

I spent some time trying to use Jersey from within the Master and it's not working. To summarize, we have unshaded resources from both jersey-server-1.19 and jersey-server-2.32 on the hbase-server classpath. Jersey's initialization uses ServiceLoader to look up concrete implementation classes of javax.ws.rs classes at runtime. Because we do not shade javax.ws.rs in hbase-thirdparty-jersey, an attempt to use shaded jersey-2.x still results in loading unshaded jersey-1.x jars, leading to an error like this

java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri(Ljava/lang/String;)Ljavax/ws/rs/core/UriBuilder;
	at javax.ws.rs.core.UriBuilder.fromUri(UriBuilder.java:96)
	at org.apache.hbase.thirdparty.org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:275)
	at org.apache.hbase.thirdparty.org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:205)
	at org.apache.hbase.thirdparty.org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:791)
	at org.apache.hbase.thirdparty.org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1626)
	at org.apache.hadoop.hbase.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:112)

We cannot override what version of these classes are loaded at runtime via Java property because Jersey's load order implementation checks system properties as a last resort, not first thing as is claimed by javadoc.

So I can think of two solutions.

1. One is to shade javax.ws.rs in hbase-thirdparty-jersey. This would shade both the interfaces and the resource files that are referenced at runtime, allowing for an entirely isolated jersey container instantiate.
2. Another idea is to add a custom ClassLoader that is inserted before jersey is initialized. This would filter out resources that are "banned", allowing our desired implementation through.

Between these, I think (1) is better, but I don't know what else might break. I've made an effort of both, but with neither approach can I get a jersey environment to response from my resource class... either because the solution is incomplete, or because I don't have the jersey environment configured properly.

See also some discussion that happened over on Slack, https://apache-hbase.slack.com/archives/C13K8NVAM/p1618857521051700

Issue Links

• is depended upon by: HBASE-25895 Implement a Cluster Metrics JSON endpoint
• is depended upon by: HBASE-25865 Visualize current state of region assignment
• relates to: HBASE-27820 HBase is not starting due to Jersey library conflicts with javax.ws.rs.api jar

Sub-Tasks

• [hbase-thirdparty] Shade javax.ws.rs package for use with shaded Jersey: Resolved
• Use shaded javax.ws.rs package classes: Resolved
• [hbase-thirdparty] Shade jackson-jaxrs-json-provider for use with shaded jersey: Resolved
• Remove javax.ws.rs-api dependency: Reopened
• Delete unnecessary dependency on jaxb-runtime jar: Resolved