[richfaces-issues] [JBoss JIRA] Updated: (RF-5212) CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the libs are put into domain1/lib folder

CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the libs are put into domain1/lib folder ---------------------------------------------------------------------------------------------------------- Key: RF-5212 URL: https://jira.jboss.org/jira/browse/RF-5212 Project: RichFaces Issue Type: Bug Components: third-party Affects Versions: 3.2.2 Environment: Sun Java System Application Server 9.2_01 Richfaces 3.2.2SR1 Reporter: John Leed Assignee: Alexander Smirnov Priority: Minor Fix For: 3.3.2.CR1 When the Richfaces 3.2.2 libs are put into a domains lib folder under SJSAS 9.2, the Admin web application breaks. This issue clones issue 1255: "I filed a bug report on glassfish https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626 , here's what they had to say about this: "In order to understand what is happening you have to know a little bit about how JSF configures itself. It looks for faces-config.xml files in the classpath to see if should add new jsf extensions (such as a new ViewHandler) to help it process jsf pages. JSF does NOT do anything to ensure that a new component (i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate that these extensions can't be restricted to a subset of URLs, or be guarenteed to behave well. In this case, Ajax4JSF does not behave well. It both of your stack traces it appears Ajax4JSF is not doing the right thing. In the first, it is not handling the rendering of the page and has either changed the viewId or done something else to cause the default viewHandler to also not handle it (it appears it is redispatching recursively b/c of this). In the 2nd example, it is attempting to handle a JSFTemplating page instead of delegating to JSFTemplating -- it is unable to do so and fails. Ajax4JSF could fix both of these problems -- I cannot. Based on these stack traces, I would strongly suggest that you not include Ajax4JSF in a shared lib area as it will effect ALL JSF applications, not just the ones you want it to effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your application(s)."" We have no other libraries that cannot be shared in the domain lib folder. Putting the RF jars into the application lib is causing a security permission failure. The permissions problem was resolvable when the jars were in the domain lib folder by changing the system.policy file. IMHO, requiring that the libraries be packaged with the app should only be a temporary fix as it increases the time and size of the build, which is a pain during development.