Bug 1064231

from IRC chat with Moti Asayag:
<masayag> ofrenkel: it seems that the jackson version is outdated, it should be >1.9.6 (on master it is 1.9.9) but the installed jackson in your env is jackson-1.9.4-6.fc19.noarch

indeed in the engine host i see:
# yum info jackson
Loaded plugins: versionlock
Installed Packages
Name        : jackson
Arch        : noarch
Version     : 1.9.4
Release     : 6.fc19
Size        : 1.2 M
Repo        : installed
From repo   : Fedora19-x86_64
Summary     : Jackson Java JSON-processor

but this is the latest i get using yum, so if another repo is needed this is not listed anywhere

Setting target release to current version for consideration and review. please
do not push non-RFE bugs to an undefined target release to make sure bugs are
reviewed for relevancy, fix, closure, etc.

This is an automated message.
Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.

Please provide jackson package with version 1.9.9 as specified in the POM of the project

Re-assigning to Juan as he's Fedora jackson default assignee.

Looks like 2.x is available in fedora >= 19. In bug #1088955 packager said that 1.x is in maintenance only mode, can't we update pom for using 2.x?

In rawhide 1.9.11 is available, will be that ok?


Installed Packages
jackson.noarch                                     1.9.4-6.fc19          @fedora
Available Packages
jackson-annotations.noarch                         2.2.2-2.fc19          updates
jackson-annotations-javadoc.noarch                 2.2.2-2.fc19          updates
jackson-core.noarch                                2.2.2-2.fc19          updates
jackson-core-javadoc.noarch                        2.2.2-2.fc19          updates
jackson-databind.noarch                            2.2.2-2.fc19          updates
jackson-databind-javadoc.noarch                    2.2.2-2.fc19          updates
jackson-dataformat-smile.noarch                    2.2.2-1.fc19          updates
jackson-dataformat-smile-javadoc.noarch            2.2.2-1.fc19          updates
jackson-dataformat-xml.noarch                      2.2.2-3.fc19          updates
jackson-dataformat-xml-javadoc.noarch              2.2.2-3.fc19          updates
jackson-javadoc.noarch                             1.9.4-6.fc19          fedora 
jackson-jaxrs-json-provider.noarch                 2.2.2-1.fc19          updates
jackson-jaxrs-providers.noarch                     2.2.2-1.fc19          updates
jackson-jaxrs-providers-javadoc.noarch             2.2.2-1.fc19          updates
jackson-jaxrs-smile-provider.noarch                2.2.2-1.fc19          updates
jackson-module-jaxb-annotations.noarch             2.2.2-2.fc19          updates
jackson-module-jaxb-annotations-javadoc.noarch     2.2.2-2.fc19          updates
jackson-module-mrbean.noarch                       2.2.2-2.fc19          updates
jackson-module-mrbean-javadoc.noarch               2.2.2-2.fc19          updates

I think that the right solution to this problem is to update the engine to use version 2.x of Jackson, as going forward we will need to do this movement anyhow.

Note that currently the engine uses the version of Jackson provided by JBoss, so using a different one will require to add a Jackson module to the backend/manager/dependencies subproject, as currently we are using the version provided by JBoss. Once we have that module we can bundle that dependency with the engine  or symlink it to the package provided by the distribution.

When we move to Wildfly we can remove this additional module, as Wildfly already provides Jackson 1.x and Jackson 2.x.

None of these tasks are Fedora packaging tasks.

Returning the bug to network whiteboard as per comment #7.

For what it may be helpful, jackson-1.9.11-3 is now provided by Fedora 19 and 20 so dependency is satisfied on Fedora.

For EL6 builds see comment #7.

(In reply to Sandro Bonazzola from comment #8)
> Returning the bug to network whiteboard as per comment #7.
> 
> For what it may be helpful, jackson-1.9.11-3 is now provided by Fedora 19
> and 20 so dependency is satisfied on Fedora.
> 
> For EL6 builds see comment #7.

we are using jackson from jboss not from external resource, we should downgrade our usage to whatever jboss provides, or we will be required to maintain yet another external library.

This is an automated message.

oVirt 3.4.1 has been released.
This issue has been retargeted to 3.5.0 since it has not been marked as high priority or severity issue, please retarget if needed.

To my understanding, and please correct me if I'm wrong, JBoss comes pre-packaged with some jackson jars, and this is what oVirt uses, no matter what jackson package the user downloads independently.

This means that to solve this, we have to either:
1. Make sure oVirt doesn't use the jackson JAR packaged as part of JBoss.
--- or ---
2. Make sure JBoss updates their usage of jackson in their next 7.1.z release (and that this release arrives soon enough).

Alon, am I correct in understanding the problem and do you agree?

(In reply to Lior Vernia from comment #11)
> To my understanding, and please correct me if I'm wrong, JBoss comes
> pre-packaged with some jackson jars, and this is what oVirt uses, no matter
> what jackson package the user downloads independently.
> 
> This means that to solve this, we have to either:
> 1. Make sure oVirt doesn't use the jackson JAR packaged as part of JBoss.

this is correct, it means that we need to pull these jars at fedora, centos, rhel(upstream), rhel(downstream).

and for upstream we have the following[1], which is 1.8.8.

> 2. Make sure JBoss updates their usage of jackson in their next 7.1.z
> release (and that this release arrives soon enough).
> 
> Alon, am I correct in understanding the problem and do you agree?

This is not a valid solution as upstream jboss will not be updated for 7.1.z... as no later fixes than 7.1.1 for this series.

Best is to avoid requiring this newer version for now, even at the price of somewhat more code. Not sure how people even tested it at current state.

[1] http://jpackage.org/browser/rpm.php?jppversion=6.0&id=16394

Since it's not oVirt code that causes this breakage but that of the OpenStack Java SDK, I don't see how we can work around this code-wise.

If we don't want to package the right jar with oVirt, this will have to wait until we adopt the next version of JBoss, so I'm postponing this to 3.6.

There is a workaround to get this to work on oVirt 3.4 and 3.5 - one may download jboss-eap (which includes a newer version of jackson) and modify the environment variable JBOSS_HOME accordingly.

Verified on - 3.6.0-0.0.master.20150412172306.git55ba764.el6

oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue.
If problems still persist, please open a new BZ and reference this one.