[
https://issues.apache.org/jira/browse/HBASE-13149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14355439#comment-14355439
]
Sean Busbey commented on HBASE-13149:
-------------------------------------
{quote}
I think the changes are in the internals of Jackson from what I see in the
report for jackson-core.
{quote}
I've attached a single report for everything, which makes it easier to spot
things that are broken.
Additionally, the release notes pointed out by [~jinghe] earlier makes it clear
that there are breaking changes:
{quote}
Here is more info on the jackson releases:
http://svn.codehaus.org/jackson/trunk/release-notes/VERSION
You can see in this Release Notes the following for 1.9:
{noformat}
Potential backwards compatibility issues (compared to 1.8.x):
* Removed 'org.codehaus.jackson.annotate.JsonClass, JsonKeyClass and
JsonContentClass (deprecated since 1.1)
* Move TokenBufferDeserializer to separate class (from inside StdDeserializer)
{noformat}
{quote}
This will break anyone relying on the old annotation approach to using JSON
with POJOs. Semver makes no allowance for removing "just deprecated stuff" on
minor version and the [jackson versioning statement doesn't carve it
out|https://github.com/FasterXML/jackson-docs#on-jackson-versioning]
{quote}
I do not realistically expect us to do a full sweep of every dependency compat
story, so we should rely on what our dependencies use for versioning. Assuming
that jackson (or other deps) uses semver or something similar going from 1.8 to
1.9 should be fine.
{quote}
I am willing to do such a check so long as we are going to make downstream
promises. I believe I can also automate it. I think the above notes on jackson
make it clear that they did not follow semver for 1.8 -> 1.9, regardless of
what their stated policy is.
{quote}
I do not think we should corner ourselves into "cannot upgrade dependencies"
situation (I think Nick Dimiduk started a thread on this some time ago). From
what I see, inconveniencing our users with not upgrading this lib in 1.1 is far
worse than upgrading it, but possibly causing some minor (if any) inconvenience
in case the user is relying on that lib explicitly.
{quote}
This is fine, provided we update our compatibility promises to reflect this
reality. There is pain in either direction, we just need to set expectations
for downstream folks. Note that options #2 and #3 I provided above will meet
the goal of fixing this by updating the dependency while having a compatibility
promise that is realistic for downstream folks.
If we are going to set a precedent that's different from our current
compatibility promises for dependencies, we should get a wider audience on dev@.
> HBase MR is broken on Hadoop 2.5+ Yarn
> --------------------------------------
>
> Key: HBASE-13149
> URL: https://issues.apache.org/jira/browse/HBASE-13149
> Project: HBase
> Issue Type: Bug
> Affects Versions: 1.0.0, 2.0.0, 0.98.10.1
> Reporter: Jerry He
> Priority: Critical
> Attachments: HBASE-13149-0.98.patch, HBASE-13149-master.patch,
> jackson-core-asl-compat_report.html, jackson-jaxrs-compat_report.html,
> jackson-mapper-asl-compat_report.html, jackson-xc-compat_report.html,
> jackson_1.8_to_1.9_compat_report.html
>
>
> Running the server MR tools is not working on Yarn version 2.5+.
> Running org.apache.hadoop.hbase.mapreduce.Export:
> {noformat}
> Exception in thread "main" java.lang.NoSuchMethodError:
> org.codehaus.jackson.map.ObjectMapper.setSerializationInclusion(Lorg/codehaus/jackson/map/annotate/JsonSerialize$Inclusion;)Lorg/codehaus/jackson/map/ObjectMapper;
> at
> org.apache.hadoop.yarn.webapp.YarnJacksonJaxbJsonProvider.configObjectMapper(YarnJacksonJaxbJsonProvider.java:59)
> at
> org.apache.hadoop.yarn.util.timeline.TimelineUtils.<clinit>(TimelineUtils.java:47)
> at
> org.apache.hadoop.yarn.client.api.impl.YarnClientImpl.serviceInit(YarnClientImpl.java:166)
> at
> org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
> at
> org.apache.hadoop.mapred.ResourceMgrDelegate.serviceInit(ResourceMgrDelegate.java:102)
> at
> org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
> at
> org.apache.hadoop.mapred.ResourceMgrDelegate.<init>(ResourceMgrDelegate.java:96)
> at org.apache.hadoop.mapred.YARNRunner.<init>(YARNRunner.java:112)
> at
> org.apache.hadoop.mapred.YarnClientProtocolProvider.create(YarnClientProtocolProvider.java:34)
> at org.apache.hadoop.mapreduce.Cluster.initialize(Cluster.java:95)
> at org.apache.hadoop.mapreduce.Cluster.<init>(Cluster.java:82)
> at org.apache.hadoop.mapreduce.Cluster.<init>(Cluster.java:75)
> at org.apache.hadoop.mapreduce.Job$9.run(Job.java:1266)
> at org.apache.hadoop.mapreduce.Job$9.run(Job.java:1262)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
> at org.apache.hadoop.mapreduce.Job.connect(Job.java:1261)
> at org.apache.hadoop.mapreduce.Job.submit(Job.java:1290)
> at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1314)
> at org.apache.hadoop.hbase.mapreduce.Export.main(Export.java:189)
> {noformat}
> The problem seems to be the jackson jar version. HADOOP-10104 updated
> jackson version to 1.9.13. YARN-2092 reported a problem as well.
> HBase is using jackson 1.8.8. This version of the jar in the classpath seem
> to cause the problem.
> Should we upgrade to jackson 1.9.13?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
