Yeah, re-reading my previous chatter with MikeD and Appy, shading in
hbase-thirdparty appears to have been the consensus.
Best as I remember, time was the only reason it didn't happen. I don't
think there's any reason we can't shade our use of Jetty, and just let
Hadoop do what they do (and instead try to get onto the shaded artifacts
everywhere we can).
Thanks for asking, Wei-Chiu!
On 2/24/20 7:01 PM, Wei-Chiu Chuang wrote:
Not sure about the real deployment, but the tests fail with
NoSuchMethodError once they start a MiniDFSCluster. (as explained in
HBASE-18943 <https://issues.apache.org/jira/browse/HBASE-18943>) I can
verify this is still the case now.
On Mon, Feb 24, 2020 at 3:53 PM Sean Busbey <[email protected]> wrote:
As an alternative, if we ensured the jetty from Hadoop wasn't in our
classpath for our service roles would that allow us to version jetty
independently? Or would we run into test problems?
On Mon, Feb 24, 2020, 16:07 Wei-Chiu Chuang <[email protected]> wrote:
Hi,
While I work on this jira HBASE-23834
<https://issues.apache.org/jira/browse/HBASE-23834> (HBase fails to run
on
Hadoop 3.3.0/3.2.2/3.1.4 due to jetty version mismatch) and I realized
this
was attempted before. But it simply doesn't work when you have Hadoop and
HBase on different Jetty minor versions (9.3 / 9.4) unless Jetty is
shaded
in HBase (or Hadoop).
We should update Jetty in HBase for sure. 9.3 has known security
vulnerabilities and not fixed until 9.4.
Given that hbase-thirdparty is the standard practice to place
thirdparty jars, should we also shade Jetty into hbase-thirdparty?
