[ 
https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_42408
 ] 

kito99 edited comment on SHALE-409 at 10/17/07 3:19 PM:
--------------------------------------------------------------

I just tried the nightly build (as of 10/17/07) with RichFaces 3.1.1 GA. I 
wasn't able to get things to work until I commented out the Shale ViewHandler 
in the JAR file's faces-config.xml (and added it as a configuration parameter 
in web.xml, as per the docs):

        <context-param>
                <param-name>org.ajax4jsf.VIEW_HANDLERS</param-name>
                <param-value>
                        
org.apache.shale.view.faces.ViewViewHandler,com.sun.facelets.FaceletViewHandler
                </param-value>
        </context-param>

(I'm obviously using Facelets.) I also had to comment out the ShaleViewRoot 
component definition in the Shale faces-config.xml. 

So my updated faces-config.xml  (in shale-view-1.1.0-SNAPSHOT.jar/META-INF) 
looks like this: 

<faces-config>

  <!-- Custom JSF Application Objects -->
  <application>
    <action-listener>
      org.apache.shale.view.faces.ViewActionListener
    </action-listener>
   <!-- <view-handler>
      org.apache.shale.view.faces.ViewViewHandler
    </view-handler>  -->
  </application>

  <!-- Custom JSF Lifecycle Objects -->
   <lifecycle>
    
<phase-listener>org.apache.shale.view.faces.ViewPhaseListener</phase-listener>
  </lifecycle> 
  
<!--
  <component>
      <description>
        Extending the UIViewRoot to provide specialized exception
        handling needed for the Shale view controller to enforce the contracts
        of the callbacks.
      </description>
      <component-type>javax.faces.ViewRoot</component-type>
      
<component-class>org.apache.shale.view.faces.ShaleViewRoot</component-class>
  </component> -->

  <!-- Custom JSF Components -->
  <component>
    <description>
      The "Subview" component performs the same services provided by the
      "subview" tag in the JSF Core Tag Library, plus it provides
      ViewController event callback services for the ViewController
      whose managed bean name is the same as the "id" value of this component.
    </description>
    <display-name>Subview</display-name>
    <component-type>org.apache.shale.view.Subview</component-type>
    
<component-class>org.apache.shale.view.faces.SubviewComponent</component-class>
  </component>

  <!-- Default Implementation Managed Beans -->
  <managed-bean>
    <description>
      Default implementation of org.apache.shale.view.ExceptionHandler
      used to process application-triggered exceptions.
    </description>
    
<managed-bean-name>org$apache$shale$view$EXCEPTION_HANDLER</managed-bean-name>
    
<managed-bean-class>org.apache.shale.view.impl.DefaultExceptionHandler</managed-bean-class>
    <managed-bean-scope>application</managed-bean-scope>
  </managed-bean>

  <managed-bean>
    <description>
      Default implementation of 
org.apache.shale.view.faces.ViewContollerCallbacks
      used to perform callbacks to the ViewController corresponding to the
      current view identifier.
    </description>
    <managed-bean-name>org$apache$shale$view$VIEW_CALLBACKS</managed-bean-name>
    
<managed-bean-class>org.apache.shale.view.faces.ViewControllerCallbacks</managed-bean-class>
    <managed-bean-scope>application</managed-bean-scope>
  </managed-bean>

  <managed-bean>
    <description>
      Default implementation of org.apache.shale.view.ViewControllerMapper
      used to map from view identifiers to the managed bean name of the
      corresponding view controller bean.
    </description>
    <managed-bean-name>org$apache$shale$view$VIEW_MAPPER</managed-bean-name>
    
<managed-bean-class>org.apache.shale.view.impl.DefaultViewControllerMapper</managed-bean-class>
    <managed-bean-scope>application</managed-bean-scope>
  </managed-bean>

</faces-config>


Now, this may actually break some of the ViewController functionality. I 
haven't tested that yet....
 

      was (Author: kito99):
    Hmm.. I'm still seeing this issue with the latest nightly build (10/17/07) 
and RichFaces 3.1. Is it just me?
  
> Shale 1.0.4+ incorrectly removes all entries in the request map after render 
> response
> -------------------------------------------------------------------------------------
>
>                 Key: SHALE-409
>                 URL: https://issues.apache.org/struts/browse/SHALE-409
>             Project: Shale
>          Issue Type: Bug
>          Components: View
>    Affects Versions: 1.0.1, 1.0.4, 1.0.5-SNAPSHOT, 1.1.0-SNAPSHOT
>         Environment: WinXP, AJAX4JSF-1.0.6+, Shale-1.0.4 (Application, Core, 
> Dialog, Spring, Tiger, View)
>            Reporter: Todd Bush
>            Assignee: Gary VanMatre
>             Fix For: 1.0.5-SNAPSHOT, 1.1.0-SNAPSHOT
>
>
> I found this issue while debugging why Shale-1.0.4 caused AJAX4JSF to stop 
> working.  Within the ViewPhaseListener.afterRenderResponse method, all 
> ViewControllers and AbstractRequestBeans are removed from the request map.  
> Then a second loop through the request map removes all other entries in an 
> attempt to remove any annotated managed beans.  AJAX4JSF relies on entries in 
> the request map while parsing the outgoing HTML, entries which are removed by 
> this phase listener.  Once I comment out the second request map loop, 
> AJAX4JSF works.  Any other technology which relies on request map entries 
> after render response will have a similar problem with Shale.
> The second loop:
>         entries = map.entrySet().iterator();
>         while (entries.hasNext()) {
>             Map.Entry entry = (Map.Entry) entries.next();
>             if (!list.contains(entry.getKey())) {
>                 list.add(entry.getKey());
>             }
>         }
> PS.  Please ignore my comment below.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to