[ https://issues.apache.org/jira/browse/HBASE-25844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Kyle Purtell updated HBASE-25844: ---------------------------------------- Fix Version/s: 2.6.0 > Fix Jersey for hbase-server processes > ------------------------------------- > > Key: HBASE-25844 > URL: https://issues.apache.org/jira/browse/HBASE-25844 > Project: HBase > Issue Type: Task > Components: master, regionserver, thirdparty > Affects Versions: 3.0.0-alpha-1, 2.5.0 > Reporter: Nick Dimiduk > Assignee: Nick Dimiduk > Priority: Major > Fix For: 2.5.0, 3.0.0-alpha-2, 2.6.0 > > > 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 > {noformat} > 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) > {noformat} > 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. > # 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. > # 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 -- This message was sent by Atlassian Jira (v8.20.1#820001)