Bug 1019637

Summary: gwt-servlet.jar cannot be moved to rhevm-dependencies
Product: Red Hat Enterprise Virtualization Manager Reporter: Alon Bar-Lev <alonbl>
Component: ovirt-engineAssignee: Alon Bar-Lev <alonbl>
Status: CLOSED CURRENTRELEASE QA Contact: Tareq Alayan <talayan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: acathrow, alonbl, dpati, eedri, iheim, juan.hernandez, kmayilsa, lpeer, mikeb, obasan, pstehlik, Rhev-m-bugs, yeylon
Target Milestone: ---   
Target Release: 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: integration
Fixed In Version: is21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1032811    
Attachments:
Description Flags
0001-packaging-spec-remove-ear-signature.patch none

Description Alon Bar-Lev 2013-10-16 07:49:21 UTC
After mead builds the java artifacts it signs the artifacts (jars, ear).

The ear contains the build time gwt-servlet.jar

Replacing the gwt-servlet.jar with different one (updated or any one that is not used for build) produces:

2013-10-15 17:54:53,856 WARN  [org.jboss.modules] (ajp-/127.0.0.1:8702-4) Failed to define class com.google.gwt.core.client.GWTBridge in Module "deployment.engine.ear.webadmin.war:main" from Service Module Loader: java.lang.SecurityException: class "com.google.gwt.core.client.GWTBridge"'s signer information does not match signer information of other classes in the same package

Removing the signature from META-INF/JBOSSCOD.SF and META-INF/MANIFEST.MF does not make jboss to ignore the signature.

Having gwt-servlet as a module will solve it, however, gwt-servlet.jar cannot be used as module (quoting Juan):
"""
Also the GWT RPC mechanism uses an incorrect class loading mechanism: it
uses the Class.forName() method instead of the context class loader,
thus, from a class loading perspective, the GWT module would need to
depend on the ovirt common module, which is conceptually wrong. That has
to be fixed before creating modules for the frontend.
"""

Comment 1 Alon Bar-Lev 2013-10-16 07:50:28 UTC
Thank you Kanagaraj for finding this!

Juan, any idea of how we may workaround this?

Comment 2 Juan Hernández 2013-10-16 09:17:01 UTC
The artifacts shouldn't be signed, and specially they shouldn't be signed with the JBoss keys. This may require a change in the build environment, in the redhat-rpm-config package.

I guess that this is happening in the build environment using by RHSC. Make sure that the version of redhat-rpm-config that you have there is the same that is in use in the RHEV-M build environment.

Mike, can you help with this?

Comment 3 Alon Bar-Lev 2013-10-16 09:55:10 UTC
(In reply to Juan Hernández from comment #2)
> I guess that this is happening in the build environment using by RHSC. Make
> sure that the version of redhat-rpm-config that you have there is the same
> that is in use in the RHEV-M build environment.

The rhevm-dependencies package was introduced so we can replace 3rd party dependencies without releasing rhevm.

So it is not local RHSC problem, but common problem for rhevm.

The jboss modules behaves correctly as they are not part of the ear so they are not signed within the ear.

The gwt-servlet.jar is included in ear, so once ear signed it cannot be replaced by other version.

Is there any way ear can add dependency like jboss module but into the main class loader? This way we remove the gwt-servlet.jar from the ear and be able to replace it with externally provided one.

Thanks!

Comment 4 Juan Hernández 2013-10-16 10:00:40 UTC
The contents of the ear shouldn't be signed. Add this to the .spec:

%global _jarsign_opts --unsign=/usr/share/ovirt-engine

Comment 5 Alon Bar-Lev 2013-10-16 10:03:06 UTC
(In reply to Juan Hernández from comment #4)
> The contents of the ear shouldn't be signed. Add this to the .spec:
> 
> %global _jarsign_opts --unsign=/usr/share/ovirt-engine

Oh... I thought we should sign.

Thanks!

Comment 6 Alon Bar-Lev 2013-10-16 12:19:09 UTC
Juan, won't the following be better?

%global _jarsign_opts --disable

Comment 7 Alon Bar-Lev 2013-10-16 12:54:58 UTC
OK... I have difficulty to understand the sequence...

The brp-jboss-sign-jars runs during post mead and during post rpmbuild.

This means that when we use mead we get pre-signed jars, and we extract the ear, so that post rpmbuild find no jar/ear, and as far as I can see brp-jboss-sign-jars only searches for jars

Comment 8 Alon Bar-Lev 2013-10-16 14:52:10 UTC
Solution is to add the following into spec, this will leave all jars as signed but the ear. As ear is exploded the brp-jboss-sign-jars cannot be instructed to unsign it as far as I can see.

#
# unsign ear
# see rhbz#1019637
# copied from redhat-rpm-config::brp-jboss-sign-jars::unsign_jarfile
#
rm -f "%{buildroot}%{engine_ear}/META-INF"/*.{DSA,RSA,SF}
perl -i -pe 'BEGIN{undef $/;} s/Name: [^\n]+\n( [^\n]+\n)*([^\s]+-Digest: [^\n]+\n(\s)?)+(Magic: [^\n]+\n)?\n//mgs' "%{buildroot}%{engine_ear}/META-INF/MANIFEST.MF"
perl -i -pe 's/^SHA1-Digest: [^\n]+\n//g' "%{buildroot}%{engine_ear}/META-INF/MANIFEST.MF"

Comment 9 Alon Bar-Lev 2013-10-16 18:59:31 UTC
Kanagaraj confirmed patch works for him.

Comment 10 Alon Bar-Lev 2013-10-16 19:00:46 UTC
Created attachment 813094 [details]
0001-packaging-spec-remove-ear-signature.patch

Comment 11 Tareq Alayan 2013-10-31 15:54:10 UTC
What to test here?

Comment 12 Alon Bar-Lev 2013-10-31 16:03:01 UTC
(In reply to Tareq Alayan from comment #11)
> What to test here?

No jars but these should be at /usr/share/ovirt-engine

# find /usr/share/ovirt-engine -type f -name '*.jar'
/usr/share/ovirt-engine/engine.ear/webadmin.war/WEB-INF/lib/gwt-extension.jar
/usr/share/ovirt-engine/engine.ear/webadmin.war/WEB-INF/lib/frontend.jar
/usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/gwt-extension.jar
/usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/frontend.jar

Comment 13 Tareq Alayan 2013-10-31 16:58:54 UTC
After clean install.
Tested on rhevm-3.3.0-0.31.beta1.el6ev.noarch


find /usr/share/ovirt-engine -type f -name '*.jar'
/usr/share/ovirt-engine/engine.ear/webadmin.war/WEB-INF/lib/gwt-extension.jar
/usr/share/ovirt-engine/engine.ear/webadmin.war/WEB-INF/lib/branding.jar
/usr/share/ovirt-engine/engine.ear/webadmin.war/WEB-INF/lib/frontend.jar
/usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/gwt-extension.jar
/usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/branding.jar
/usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/frontend.jar
/usr/share/ovirt-engine/engine.ear/restapi.war/WEB-INF/lib/branding.jar
/usr/share/ovirt-engine/engine.ear/root.war/WEB-INF/lib/branding.jar


is this ok?

Comment 14 Alon Bar-Lev 2013-10-31 18:05:08 UTC
(In reply to Tareq Alayan from comment #13)
> After clean install.
> Tested on rhevm-3.3.0-0.31.beta1.el6ev.noarch
> 
> 
> find /usr/share/ovirt-engine -type f -name '*.jar'
> /usr/share/ovirt-engine/engine.ear/webadmin.war/WEB-INF/lib/gwt-extension.jar
> /usr/share/ovirt-engine/engine.ear/webadmin.war/WEB-INF/lib/branding.jar
> /usr/share/ovirt-engine/engine.ear/webadmin.war/WEB-INF/lib/frontend.jar
> /usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/gwt-extension.
> jar
> /usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/branding.jar
> /usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/frontend.jar
> /usr/share/ovirt-engine/engine.ear/restapi.war/WEB-INF/lib/branding.jar
> /usr/share/ovirt-engine/engine.ear/root.war/WEB-INF/lib/branding.jar
> 
> 
> is this ok?

yes, this is newer version than what I pasted my output from.

thanks!

Comment 15 Itamar Heim 2014-01-21 22:28:38 UTC
Closing - RHEV 3.3 Released

Comment 16 Itamar Heim 2014-01-21 22:28:40 UTC
Closing - RHEV 3.3 Released

Comment 17 Itamar Heim 2014-01-21 22:31:37 UTC
Closing - RHEV 3.3 Released