[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

[Nick Belaevski (JIRA)]

     [ https://jira.jboss.org/jira/browse/RF-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nick Belaevski updated RF-5212:
-------------------------------

    Fix Version/s: Future
                       (was: 3.2.1)
         Assignee: Nick Belaevski  (was: Tsikhon Kuprevich)


> 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
>    Affects Versions: 3.2.2
>         Environment: Sun Java System Application Server 9.2_01
> Richfaces 3.2.2SR1
>            Reporter: John Leed
>            Assignee: Nick Belaevski
>             Fix For: Future
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira