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. """
Thank you Kanagaraj for finding this! Juan, any idea of how we may workaround this?
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?
(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!
The contents of the ear shouldn't be signed. Add this to the .spec: %global _jarsign_opts --unsign=/usr/share/ovirt-engine
(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!
Juan, won't the following be better? %global _jarsign_opts --disable
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
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"
Kanagaraj confirmed patch works for him.
Created attachment 813094 [details] 0001-packaging-spec-remove-ear-signature.patch
What to test here?
(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
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?
(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!
Closing - RHEV 3.3 Released