Created: (SHALE-409) Shale 1.0.4+ breaks AJAX4JSF

Discussion:

Todd Bush (JIRA)

2007-02-13 15:20:16 UTC

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>
<script type="text/javascript" src="/crown/a4j.res/org.ajax4jsf.framework.ajax.AjaxScript.xhtml">
</script><meta http-equiv="Cache-Control" content="no-store" />

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>
<meta http-equiv="Cache-Control" content="no-store" />

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.

Todd Bush (JIRA)

2007-03-13 19:50:51 UTC

Permalink

[ 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

Post by Todd Bush (JIRA)
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>
<script type="text/javascript" src="/crown/a4j.res/org.ajax4jsf.framework.ajax.AjaxScript.xhtml">
</script><meta http-equiv="Cache-Control" content="no-store" />
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>
<meta http-equiv="Cache-Control" content="no-store" />
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.

Todd Bush (JIRA)

2007-03-15 12:09:51 UTC

Permalink

[ 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>
<script type="text/javascript" src="/crown/a4j.res/org.ajax4jsf.framework.ajax.AjaxScript.xhtml">
</script><meta http-equiv="Cache-Control" content="no-store" />

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>
<meta http-equiv="Cache-Control" content="no-store" />

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.
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.

Todd Bush (JIRA)

2007-03-15 12:11:51 UTC

Permalink

Post by Todd Bush (JIRA)
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.
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.

Radim Vachtl (JIRA)

2007-04-25 10:04:42 UTC

Permalink

[ 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.

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

Matt Hughes (JIRA)

2007-05-01 18:11:42 UTC

Permalink

[ 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);
}
}
}

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

Lionel Port (JIRA)

2007-05-11 00:13:42 UTC

Permalink

[ 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.

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

Mario Buonopane (JIRA)

2007-05-22 13:39:42 UTC

Permalink

[ 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

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

Mario Buonopane (JIRA)

2007-05-22 13:41:43 UTC

Permalink

[ 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

Post by Todd Bush (JIRA)
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.
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.

Gary VanMatre (JIRA)

2007-07-27 18:29:06 UTC

Permalink

[ 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

Post by Todd Bush (JIRA)
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.
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.

Gary VanMatre (JIRA)

2007-07-27 18:29:05 UTC

Permalink

[ 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

Post by Todd Bush (JIRA)
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.
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.

Gary VanMatre (JIRA)

2007-07-27 18:53:05 UTC

Permalink

[ 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.

Post by Todd Bush (JIRA)
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.
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.

Kito D. Mann (JIRA)

2007-10-17 12:32:40 UTC

Permalink

[ 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?

Post by Todd Bush (JIRA)
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.
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.

Kito D. Mann (JIRA)

2007-10-17 22:20:39 UTC

Permalink

Post by Todd Bush (JIRA)
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.
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.

Kito D. Mann (JIRA)

2007-10-17 22:20:39 UTC

Permalink

[ 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>


<application>
<action-listener>
org.apache.shale.view.faces.ViewActionListener
</action-listener>

</application>


<lifecycle>
<phase-listener>org.apache.shale.view.faces.ViewPhaseListener</phase-listener>
</lifecycle>




<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>


<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>


<application>
<action-listener>
org.apache.shale.view.faces.ViewActionListener
</action-listener>

</application>


<lifecycle>
<phase-listener>org.apache.shale.view.faces.ViewPhaseListener</phase-listener>
</lifecycle>




<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>


<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....

Post by Todd Bush (JIRA)
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.
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.

payne (JIRA)

2008-09-19 03:43:25 UTC

Permalink

[ 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

Post by Todd Bush (JIRA)
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.
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.

Craig McClanahan (JIRA)

2008-09-25 04:26:25 UTC

Permalink

[ 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

Post by Todd Bush (JIRA)
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.
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.

Shridhar N S (JIRA)

2009-02-09 18:02:03 UTC

Permalink

[ 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

Post by Todd Bush (JIRA)
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.
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.

Shridhar N S (JIRA)

2009-02-09 19:18:46 UTC

Permalink

[ 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

Post by Todd Bush (JIRA)
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.
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.

eneri@imap.custodix.com (JIRA)

2009-02-09 19:20:47 UTC

Permalink

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

***@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 ***@custodix.com for any inquiries.

Kind regards,

Elias

Post by Todd Bush (JIRA)
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.
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.