Hide Forgot
+++ 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.
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
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.
Agree on technical note
Modified release notes text.
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
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.