[richfaces-issues] [JBoss JIRA] Commented: (RF-1255) Richfaces 3.1.2 breaks SJSAS 9.1 Admin web-app, when the libs are put into domain1/lib folder

[Sergey Smirnov (JIRA)]

    [ http://jira.jboss.com/jira/browse/RF-1255?page=comments#action_12385369 ] 
            
Sergey Smirnov commented on RF-1255:
------------------------------------

Ajax4jsf does not exist anymore. Its functionality has been included into the RichFaces.
RichFaces has three jar files. API, IMPL and UI. Only API should in in shared lib folder.

> Richfaces 3.1.2 breaks SJSAS 9.1 Admin web-app, when the libs are put into domain1/lib folder
> ---------------------------------------------------------------------------------------------
>
>                 Key: RF-1255
>                 URL: http://jira.jboss.com/jira/browse/RF-1255
>             Project: RichFaces
>          Issue Type: Bug
>         Environment: Sun Java System Application Server 9.1 (build b58g-fcs)
> Richfaces 3.1.2
>            Reporter: Rene Rattur
>         Assigned To: Alexander Smirnov
>             Fix For: 3.2.0
>
>         Attachments: stack_trace.zip
>
>
> When the Richfaces 3.1.2 libs are put into a domains lib folder under SJSAS 9.1, the Admin web application breaks.
> 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)."

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