You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shale.apache.org by "Todd Bush (JIRA)" <ji...@apache.org> on 2007/02/13 16:20:16 UTC
[jira] Created: (SHALE-409) Shale 1.0.4+ breaks AJAX4JSF
Shale 1.0.4+ breaks AJAX4JSF
----------------------------
Key: SHALE-409
URL: https://issues.apache.org/struts/browse/SHALE-409
Project: Shale
Issue Type: Bug
Components: View
Affects Versions: 1.0.4, 1.0.5-SNAPSHOT
Environment: WinXP, AJAX4JSF-1.0.6, Shale-1.0.4 (Application, Core, Dialog, Spring, Tiger, View)
Reporter: Todd Bush
I've successfully implemented AJAX4JSF-1.0.6 with Shale-1.0.3, but when I attempt to upgrade Shale to 1.0.4 (also 1.0.5-SNAPSHOT) the a4j functionality stops working. I receive no stack trace or other server side error. I do receive a javascript error "A4J is undefined".
Viewing the output when running Shale-1.0.3, this javascript URL reference exists or A4J ...
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:acegijsf="http://sourceforge.net/projects/jsf-comp/acegijsf"><head><title></title><!-- HTTP 1.1 -->
<script type="text/javascript" src="/crown/a4j.res/org.ajax4jsf.framework.ajax.AjaxScript.xhtml">
</script><meta http-equiv="Cache-Control" content="no-store" /><!-- HTTP 1.0 -->
With Shale-1.0.4, the same page is missing the javascript URL reference for A4J ...
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:acegijsf="http://sourceforge.net/projects/jsf-comp/acegijsf"><head><title></title><!-- HTTP 1.1 -->
<meta http-equiv="Cache-Control" content="no-store" /><!-- HTTP 1.0 -->
Also, a Nabble references detailing the same problem
http://www.nabble.com/Solved!-A4J-is-Undefined-t3152071.html
http://www.nabble.com/AJAX4JSF---Shale-1.0.4-t3148641.html
Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Gary VanMatre (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary VanMatre updated SHALE-409:
--------------------------------
Affects Version/s: 1.0.1
Fix Version/s: 1.1.0-SNAPSHOT
1.0.5-SNAPSHOT
> 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.
[jira] Commented: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Shridhar N S (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45566#action_45566 ]
Shridhar N S commented on SHALE-409:
------------------------------------
Hi,
Here is the environment details:
Java 1.6.0_04
SJSAS/Glassfish 9.1.2.3
Jericho-HTML 2.5
Apache JCS 1.3
Apache Shale 1.0.5
Apache Commons (lang2.3,codec1.3;el1.0;pool1.3;io1.4;upload1.2.1)
Apache Tomahawk 1.1.7-jsf1.2
Rich Faces 3.3.0
Also we're not using facelets, instead using jsps. Let me know if any further details are needed that could help the cause.
Thanks,
Shridhar
> 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
>
>
> 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.
[jira] Issue Comment Edited: (SHALE-409) Shale 1.0.4+ incorrectly
removes all entries in the request map after render response
Posted by "Kito D. Mann (JIRA)" <ji...@apache.org>.
[ 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:20 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 RichFaces 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):
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....
> 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.
[jira] Commented: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Lionel Port (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40963 ]
Lionel Port commented on SHALE-409:
-----------------------------------
Beyond just commenting out the code to remove the keys from the request, it looks like that whole function is redundant.
All it does is populate a list that will never be used again and remove all the request attributes.
> 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.4, 1.0.5-SNAPSHOT
> Environment: WinXP, AJAX4JSF-1.0.6+, Shale-1.0.4 (Application, Core, Dialog, Spring, Tiger, View)
> Reporter: Todd Bush
>
> 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.
[jira] Commented: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Matt Hughes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40918 ]
Matt Hughes commented on SHALE-409:
-----------------------------------
There clearly is a bug in this method. In the first while block, it finds all keys in the request map whose value is of a certain type. And then in the second while block, it finds all keys in the map that it hasn't already added before. Therefore, after the second while block, the 'list' variable has EVERY KEY that was in the original map. If that is really what you intended, you could have made the method a lot simpler: map.clear(). I would submit a fix for this but I really can't figure out what that second while block is trying to do. Any ideas? This bug breaks ajax4jsf as well as any other library expecting their request attributes to stay put.
// In ViewPhaseListener
private void afterRenderResponse(PhaseEvent event) {
// Initialize local values we will need
Map map = event.getFacesContext().getExternalContext().getRequestMap();
// Remove our list of initialized views explicitly
map.remove(FacesConstants.VIEWS_INITIALIZED);
List list = new ArrayList();
Iterator entries = map.entrySet().iterator();
// First select all the ViewController and AbstractRequestBean instances
while (entries.hasNext()) {
Map.Entry entry = (Map.Entry) entries.next();
if ((entry.getValue() instanceof ViewController)
|| (entry.getValue() instanceof AbstractRequestBean)) {
list.add(entry.getKey());
}
}
// Second select all remaining instances, which will include annotated
// managed beans if Shale Tiger is present
entries = map.entrySet().iterator();
while (entries.hasNext()) {
Map.Entry entry = (Map.Entry) entries.next();
if (!list.contains(entry.getKey())) {
list.add(entry.getKey());
}
}
// Iterate through the keys in the specified order, removing the
// corresponding request scope attribute instances
Iterator keys = list.iterator();
while (keys.hasNext()) {
String key = (String) keys.next();
try {
//map.remove(key);
} catch (Exception e) {
handleException(event.getFacesContext(), e);
}
}
}
> 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.4, 1.0.5-SNAPSHOT
> Environment: WinXP, AJAX4JSF-1.0.6+, Shale-1.0.4 (Application, Core, Dialog, Spring, Tiger, View)
> Reporter: Todd Bush
>
> 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.
[jira] Commented: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Radim Vachtl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40898 ]
Radim Vachtl commented on SHALE-409:
------------------------------------
I think I am facing this problem as well. I would like to use Tomahawk with JSPs. If I enable the MyFacesExtensionsFilter (which is needed for Tomahawk) then I'm getting following warning for each request:
[DefaultAddResource] - MyFaces special javascript could not be retrieved from request-map.
> 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.4, 1.0.5-SNAPSHOT
> Environment: WinXP, AJAX4JSF-1.0.6+, Shale-1.0.4 (Application, Core, Dialog, Spring, Tiger, View)
> Reporter: Todd Bush
>
> 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.
[jira] Commented: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Shridhar N S (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45562#action_45562 ]
Shridhar N S commented on SHALE-409:
------------------------------------
Hi,
I tried to make all the changes suggested above. I could get a4j working (all the resources get built etc). But whenever, I have any a4j tag that interacts with the bean (like a4j: commandButton, a4j:support etc) I have to surround them with a4j:region. After this change, instead of refreshing only the region (s) mentioned in reRender options, it refreshes the whole page. Any help is much appreciated.
Thanks,
Shridhar
> 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
>
>
> 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.
[jira] Updated: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Todd Bush (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Bush updated SHALE-409:
----------------------------
Description:
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());
}
}
was:
I've successfully implemented AJAX4JSF-1.0.6 with Shale-1.0.3, but when I attempt to upgrade Shale to 1.0.4 (also 1.0.5-SNAPSHOT) the a4j functionality stops working. I receive no stack trace or other server side error. I do receive a javascript error "A4J is undefined".
Viewing the output when running Shale-1.0.3, this javascript URL reference exists or A4J ...
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:acegijsf="http://sourceforge.net/projects/jsf-comp/acegijsf"><head><title></title><!-- HTTP 1.1 -->
<script type="text/javascript" src="/crown/a4j.res/org.ajax4jsf.framework.ajax.AjaxScript.xhtml">
</script><meta http-equiv="Cache-Control" content="no-store" /><!-- HTTP 1.0 -->
With Shale-1.0.4, the same page is missing the javascript URL reference for A4J ...
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:acegijsf="http://sourceforge.net/projects/jsf-comp/acegijsf"><head><title></title><!-- HTTP 1.1 -->
<meta http-equiv="Cache-Control" content="no-store" /><!-- HTTP 1.0 -->
Also, a Nabble references detailing the same problem
http://www.nabble.com/Solved!-A4J-is-Undefined-t3152071.html
http://www.nabble.com/AJAX4JSF---Shale-1.0.4-t3148641.html
Thanks.
Environment: WinXP, AJAX4JSF-1.0.6+, Shale-1.0.4 (Application, Core, Dialog, Spring, Tiger, View) (was: WinXP, AJAX4JSF-1.0.6, Shale-1.0.4 (Application, Core, Dialog, Spring, Tiger, View))
Summary: Shale 1.0.4+ incorrectly removes all entries in the request map after render response (was: Shale 1.0.4+ breaks AJAX4JSF)
> 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.4, 1.0.5-SNAPSHOT
> Environment: WinXP, AJAX4JSF-1.0.6+, Shale-1.0.4 (Application, Core, Dialog, Spring, Tiger, View)
> Reporter: Todd Bush
>
> 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());
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Kito D. Mann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_42408 ]
Kito D. Mann commented on SHALE-409:
------------------------------------
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.
[jira] Commented: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "payne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44734#action_44734 ]
payne commented on SHALE-409:
-----------------------------
http://templora.com/index.php/topic,793.0.html
http://templora.com/index.php/topic,792.0.html
http://templora.com/index.php/topic,791.0.html
http://templora.com/index.php/topic,790.0.html
http://templora.com/index.php/topic,789.0.html
http://templora.com/index.php/topic,788.0.html
http://templora.com/index.php/topic,787.0.html
http://templora.com/index.php/topic,786.0.html
http://templora.com/index.php/topic,785.0.html
http://templora.com/index.php/topic,784.0.html
http://templora.com/index.php/topic,783.0.html
http://templora.com/index.php/topic,782.0.html
http://templora.com/index.php/topic,781.0.html
http://templora.com/index.php/topic,780.0.html
http://templora.com/index.php/topic,779.0.html
http://templora.com/index.php/topic,778.0.html
http://templora.com/index.php/topic,777.0.html
http://templora.com/index.php/topic,776.0.html
http://templora.com/index.php/topic,775.0.html
http://templora.com/index.php/topic,774.0.html
http://templora.com/index.php/topic,773.0.html
http://templora.com/index.php/topic,772.0.html
http://templora.com/index.php/topic,771.0.html
http://templora.com/index.php/topic,770.0.html
http://templora.com/index.php/topic,769.0.html
http://templora.com/index.php/topic,768.0.html
http://templora.com/index.php/topic,767.0.html
http://templora.com/index.php/topic,766.0.html
http://templora.com/index.php/topic,765.0.html
http://templora.com/index.php/topic,764.0.html
http://templora.com/index.php/topic,763.0.html
http://templora.com/index.php/topic,762.0.html
http://templora.com/index.php/topic,761.0.html
http://templora.com/index.php/topic,760.0.html
http://templora.com/index.php/topic,759.0.html
http://templora.com/index.php/topic,758.0.html
http://templora.com/index.php/topic,757.0.html
http://templora.com/index.php/topic,756.0.html
http://templora.com/index.php/topic,755.0.html
http://templora.com/index.php/topic,754.0.html
http://templora.com/index.php/topic,753.0.html
http://templora.com/index.php/topic,752.0.html
http://templora.com/index.php/topic,751.0.html
http://templora.com/index.php/topic,750.0.html
http://templora.com/index.php/topic,749.0.html
http://templora.com/index.php/topic,748.0.html
http://templora.com/index.php/topic,747.0.html
http://templora.com/index.php/topic,746.0.html
http://templora.com/index.php/topic,745.0.html
http://templora.com/index.php/topic,744.0.html
http://templora.com/index.php/topic,743.0.html
http://templora.com/index.php/topic,742.0.html
http://templora.com/index.php/topic,741.0.html
http://templora.com/index.php/topic,740.0.html
http://templora.com/index.php/topic,739.0.html
http://templora.com/index.php/topic,738.0.html
http://templora.com/index.php/topic,737.0.html
http://templora.com/index.php/topic,736.0.html
http://templora.com/index.php/topic,735.0.html
http://templora.com/index.php/topic,734.0.html
http://templora.com/index.php/topic,733.0.html
http://templora.com/index.php/topic,732.0.html
http://templora.com/index.php/topic,731.0.html
http://templora.com/index.php/topic,730.0.html
http://templora.com/index.php/topic,729.0.html
http://templora.com/index.php/topic,728.0.html
http://templora.com/index.php/topic,727.0.html
http://templora.com/index.php/topic,726.0.html
http://templora.com/index.php/topic,725.0.html
http://templora.com/index.php/topic,724.0.html
http://templora.com/index.php/topic,723.0.html
http://templora.com/index.php/topic,722.0.html
http://templora.com/index.php/topic,721.0.html
http://templora.com/index.php/topic,720.0.html
http://templora.com/index.php/topic,719.0.html
http://templora.com/index.php/topic,718.0.html
http://templora.com/index.php/topic,717.0.html
http://templora.com/index.php/topic,716.0.html
http://templora.com/index.php/topic,715.0.html
http://templora.com/index.php/topic,714.0.html
http://templora.com/index.php/topic,713.0.html
http://templora.com/index.php/topic,712.0.html
http://templora.com/index.php/topic,711.0.html
http://templora.com/index.php/topic,710.0.html
http://templora.com/index.php/topic,709.0.html
http://templora.com/index.php/topic,708.0.html
http://templora.com/index.php/topic,707.0.html
http://templora.com/index.php/topic,706.0.html
http://templora.com/index.php/topic,705.0.html
http://templora.com/index.php/topic,704.0.html
http://templora.com/index.php/topic,703.0.html
http://templora.com/index.php/topic,702.0.html
http://templora.com/index.php/topic,701.0.html
http://templora.com/index.php/topic,700.0.html
http://templora.com/index.php/topic,699.0.html
http://templora.com/index.php/topic,698.0.html
http://templora.com/index.php/topic,697.0.html
http://templora.com/index.php/topic,696.0.html
http://templora.com/index.php/topic,695.0.html
http://templora.com/index.php/topic,694.0.html
> 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
>
>
> 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.
[jira] Updated: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Mario Buonopane (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mario Buonopane updated SHALE-409:
----------------------------------
Affects Version/s: 1.1.0-SNAPSHOT
> 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.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
>
> 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.
[jira] Updated: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig McClanahan updated SHALE-409:
-----------------------------------
Comment: was deleted
> 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
>
>
> 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.
[jira] Assigned: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Gary VanMatre (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary VanMatre reassigned SHALE-409:
-----------------------------------
Assignee: Gary VanMatre
> 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.
[jira] Issue Comment Edited: (SHALE-409) Shale 1.0.4+ incorrectly
removes all entries in the request map after render response
Posted by "Kito D. Mann (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Mario Buonopane (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41086 ]
Mario Buonopane commented on SHALE-409:
---------------------------------------
I receive the same error using Shale 1.1.0-SNAPSHOT
> 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.4, 1.0.5-SNAPSHOT
> Environment: WinXP, AJAX4JSF-1.0.6+, Shale-1.0.4 (Application, Core, Dialog, Spring, Tiger, View)
> Reporter: Todd Bush
>
> 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.
[jira] Updated: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Todd Bush (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Bush updated SHALE-409:
----------------------------
Description:
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.
was:
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());
}
}
> 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.4, 1.0.5-SNAPSHOT
> Environment: WinXP, AJAX4JSF-1.0.6+, Shale-1.0.4 (Application, Core, Dialog, Spring, Tiger, View)
> Reporter: Todd Bush
>
> 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.
[jira] Commented: (SHALE-409) Shale 1.0.4+ breaks AJAX4JSF
Posted by "Todd Bush (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40544 ]
Todd Bush commented on SHALE-409:
---------------------------------
Doing more investigation into this issue, I found the problem is within ViewPhaseListener.afterRenderResponse. Within this method, the code is basically removing all entries within the RequestMap during the second loop through the map. Since AJAX4JSF relies on requestMap entries while parsing the outgoing HTML, all expected entries are missing. Once I commented out the second loop, AJAX4JSF works correctly.
I'm sure any other technologies which rely on requestMap entries after the render response phase will suffer from a similar problem.
Thanks
> Shale 1.0.4+ breaks AJAX4JSF
> ----------------------------
>
> Key: SHALE-409
> URL: https://issues.apache.org/struts/browse/SHALE-409
> Project: Shale
> Issue Type: Bug
> Components: View
> Affects Versions: 1.0.4, 1.0.5-SNAPSHOT
> Environment: WinXP, AJAX4JSF-1.0.6, Shale-1.0.4 (Application, Core, Dialog, Spring, Tiger, View)
> Reporter: Todd Bush
>
> I've successfully implemented AJAX4JSF-1.0.6 with Shale-1.0.3, but when I attempt to upgrade Shale to 1.0.4 (also 1.0.5-SNAPSHOT) the a4j functionality stops working. I receive no stack trace or other server side error. I do receive a javascript error "A4J is undefined".
> Viewing the output when running Shale-1.0.3, this javascript URL reference exists or A4J ...
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:acegijsf="http://sourceforge.net/projects/jsf-comp/acegijsf"><head><title></title><!-- HTTP 1.1 -->
> <script type="text/javascript" src="/crown/a4j.res/org.ajax4jsf.framework.ajax.AjaxScript.xhtml">
> </script><meta http-equiv="Cache-Control" content="no-store" /><!-- HTTP 1.0 -->
> With Shale-1.0.4, the same page is missing the javascript URL reference for A4J ...
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:acegijsf="http://sourceforge.net/projects/jsf-comp/acegijsf"><head><title></title><!-- HTTP 1.1 -->
> <meta http-equiv="Cache-Control" content="no-store" /><!-- HTTP 1.0 -->
> Also, a Nabble references detailing the same problem
> http://www.nabble.com/Solved!-A4J-is-Undefined-t3152071.html
> http://www.nabble.com/AJAX4JSF---Shale-1.0.4-t3148641.html
> Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "eneri@imap.custodix.com (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45568#action_45568 ]
eneri@imap.custodix.com commented on SHALE-409:
-----------------------------------------------
Hello,
Iâm on vacation from 2 February till the 20th .
As I probably wonât have an internet connection where Iâm staying,
please contact support@custodix.com for any inquiries.
Kind regards,
Elias
> 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
>
>
> 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.
[jira] Resolved: (SHALE-409) Shale 1.0.4+ incorrectly removes all
entries in the request map after render response
Posted by "Gary VanMatre (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/SHALE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary VanMatre resolved SHALE-409.
---------------------------------
Resolution: Fixed
Fix in the 20070728 nightly build.
> 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.