Bug 769022

Summary: EWS Hibernate 3.3 causes security check failure when combined with RichFaces 3.3
Product: [Retired] JBoss Enterprise WFK Platform 2 Reporter: Karel Piwko <kpiwko>
Component: SpringAssignee: Petr Penicka <ppenicka>
Status: CLOSED DEFERRED QA Contact: Karel Piwko <kpiwko>
Severity: high Docs Contact:
Priority: high    
Version: 2.0.0.DR06CC: irooskov, lpearce, mnovotny, myarboro, ppenicka
Target Milestone: ---   
Target Release: 2.3.0   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/JBWFK-109
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Packaging Hibernate 3.3 and RichFaces 3.3 libraries in an application using JBoss Enterprise Web Server causes the security check to fail. This is due to a combination of signed and unsigned jars. This is because the Hibernate JAR files in Enterprise Web Server come signed, and both Hibernate and RichFaces have a transitive dependency on the package: commons-collections, which is not shipped. The workaround for this issue is to use the community version of commons-collections within a Hibernate application that also uses RichFaces.
Story Points: ---
Clone Of: 724747 Environment:
EWS 1.0.2
Last Closed: 2013-02-28 15:30:26 UTC 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: 724747    
Bug Blocks:    

Description Karel Piwko 2011-12-19 17:08:54 UTC
+++ This bug was initially created as a clone of Bug #724747 +++

Affects: Documentation (Ref Guide, User Guide, etc.), Release Notes
Workaround: Workaround Exists
Workaround Description: Variant one: Do not use commons-collections artifact within an application which uses RichFaces as well, use rather community version of commons-collections.

Variant two: Use (unreleased) Wolf repository, which has signed commons-digester and commons-beanutils.
securitylevel_name: Public

EWS 1.0.2 is the first EWS version which distributes Hibernate, the jars there come signed.

Hibernate has transitive dependency on commons-collections, which is a part of Hibernate distribution in EWS as signed jar.

RichFaces has transitive dependency on commons-collections, commons-beanutils and commons-digester. RichFaces is distributed within WFK as signed jars,
however transitive dependencies are not shipped.

When a developer packages Hibernate and Richfaces libs in a application, he gets a combination of signed commons-collections and unsigned commons-digester.
This leads to fail during security check:

{code}
SEVERE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener
com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! class "org.apache.commons.collections.ArrayStack"'s signer information does not match signer information of other classes in the same package
	at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:215)
	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:196)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4205)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4704)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601)
	at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:943)
	at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:778)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:504)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1315)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:324)
	at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1061)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:840)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463)
	at org.apache.catalina.core.StandardService.start(StandardService.java:525)
	at org.apache.catalina.core.StandardServer.start(StandardServer.java:754)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:595)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
Caused by: java.lang.SecurityException: class "org.apache.commons.collections.ArrayStack"'s signer information does not match signer information of other classes in the same package
	at java.lang.ClassLoader.checkCerts(ClassLoader.java:807)
	at java.lang.ClassLoader.preDefineClass(ClassLoader.java:488)
	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:626)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
	at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2818)
	at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1159)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1647)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526)
	at org.apache.commons.digester.Digester.<init>(Digester.java:153)
	at org.ajax4jsf.resource.ResourceBuilderImpl.registerConfig(ResourceBuilderImpl.java:169)
	at org.ajax4jsf.resource.ResourceBuilderImpl.registerResources(ResourceBuilderImpl.java:153)
	at org.ajax4jsf.resource.ResourceBuilderImpl.init(ResourceBuilderImpl.java:224)
	at org.ajax4jsf.renderkit.ChameleonRenderKitFactory.<init>(ChameleonRenderKitFactory.java:62)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
	at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:519)
	at javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:405)
	at javax.faces.FactoryFinder.access$400(FactoryFinder.java:135)
	at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:717)
	at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:239)
	at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:186)
	at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:131)
	at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:205)
	... 25 more
{code}

--- Additional comment from kpiwko on 2011-05-31 10:58:25 EDT ---

Link: Added: This issue is incorporated by JBWFK-112


--- Additional comment from rebecca.jboss on 2011-05-31 23:49:24 EDT ---

Release Notes Docs Status: Removed: Not Yet Documented Added: Documented as Known Issue
Release Notes Text: Added: Packaging Hibernate and RichFaces libraries in an application using Enterprise Web Server causes the security check to fail, due to a combination of signed and unsigned jars. This is because the Hibernate jars in Enterprise Web Server come signed, and Hibernate has a transitive dependency on commons-collections. RichFaces has a transitive dependency on commons-collections, and commons-digester, but transitive dependencies are not shipped. The workaround for this issue is to use the community version of commons-collections within an application that also uses RichFaces.

Comment 1 Karel Piwko 2011-12-19 17:10:36 UTC
Caused by following class present in both commons-collections and commons-beanutils, which one of them is signed:

org.apache.commons.collections.ArrayStack	

commons-beanutils-1.7.0.jar , commons-beanutils-1.8.0.jar , commons-collections-2.1.1.jar , commons-collections-3.1-wfk-4.jar , commons-collections-3.1.jar , commons-collections-3.2.1.jar , commons-collections-3.2.jar

Comment 3 Rebecca Newton 2012-02-28 03:36:34 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Packaging Hibernate and RichFaces libraries in an
application using Enterprise Web Server causes the security check to fail, due
to a combination of signed and unsigned jars. This is because the Hibernate
jars in Enterprise Web Server come signed, and Hibernate has a transitive
dependency on commons-collections. RichFaces has a transitive dependency on
commons-collections, and commons-digester, but transitive dependencies are not
shipped. The workaround for this issue is to use the community version of
commons-collections within an application that also uses RichFaces.

Comment 5 Marius Bogoevici 2012-04-12 20:29:19 UTC
Agree on technical note

Comment 6 Karel Piwko 2012-05-21 15:00:26 UTC
Modified release notes text.

Comment 7 Karel Piwko 2012-05-21 15:00:26 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,4 +1,4 @@
-Packaging Hibernate and RichFaces libraries in an
+Packaging Hibernate 3.3 and RichFaces 3.3 libraries in an
 application using Enterprise Web Server causes the security check to fail, due
 to a combination of signed and unsigned jars. This is because the Hibernate
 jars in Enterprise Web Server come signed, and Hibernate has a transitive

Comment 13 Karel Piwko 2013-02-28 15:30:26 UTC
I'm closing this issue as DEFERRED because it affects WFK 1.2 to WFK 2.0 migration. There is no delivery channel for WFK 2.2 to fix that issue.