[JBoss JIRA] (RF-12839) Toggle panels: ajax-related attributes do not work
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12839?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12839:
------------------------------------
Note however, that the non-working ajax attributes of the non-tab toggle items have been removed.
> Toggle panels: ajax-related attributes do not work
> --------------------------------------------------
>
> Key: RF-12839
> URL: https://issues.jboss.org/browse/RF-12839
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.3.1
> Environment: RichFaces 4.3.2-SNAPSHOT
> Metamer 4.3.2-SNAPSHOT
> JBoss Application Server: Weld Integration 7.1.3.Final-redhat-4
> JBoss AS 7.1.3.Final-redhat-4
> Java(TM) SE Runtime Environment 1.7.0_04-b20 @ Linux
> Chrome 25.0.1364.160 @ Linux x86_64
> Reporter: Pavol Pitonak
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.3.2
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/richTab/simple.xhtml
> # set oncomplete to "alert('complete')"
> # switch to tab 2 and back to tab 1
> result:
> * alert should be diplayed but isn't
> * tabs are correctly switched
> * worked fine in 4.2.3.Final
> * several attributes don't work - onbegin, onbeforedomupdate, oncomplete, data, execute, immediate, render, limitRender, status
> * affected components: tab, toggle panel item, accordion item
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (RF-12839) Toggle panels: ajax-related attributes do not work
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12839?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-12839.
--------------------------------
Resolution: Done
> Toggle panels: ajax-related attributes do not work
> --------------------------------------------------
>
> Key: RF-12839
> URL: https://issues.jboss.org/browse/RF-12839
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.3.1
> Environment: RichFaces 4.3.2-SNAPSHOT
> Metamer 4.3.2-SNAPSHOT
> JBoss Application Server: Weld Integration 7.1.3.Final-redhat-4
> JBoss AS 7.1.3.Final-redhat-4
> Java(TM) SE Runtime Environment 1.7.0_04-b20 @ Linux
> Chrome 25.0.1364.160 @ Linux x86_64
> Reporter: Pavol Pitonak
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.3.2
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/richTab/simple.xhtml
> # set oncomplete to "alert('complete')"
> # switch to tab 2 and back to tab 1
> result:
> * alert should be diplayed but isn't
> * tabs are correctly switched
> * worked fine in 4.2.3.Final
> * several attributes don't work - onbegin, onbeforedomupdate, oncomplete, data, execute, immediate, render, limitRender, status
> * affected components: tab, toggle panel item, accordion item
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (RF-12839) Toggle panels: ajax-related attributes do not work
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12839?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12839:
------------------------------------
The _execute_ attribute of the tab component was broken with the resolution of RF-12513, with the commit:
https://github.com/richfaces/components/commit/0d7c51a
> Toggle panels: ajax-related attributes do not work
> --------------------------------------------------
>
> Key: RF-12839
> URL: https://issues.jboss.org/browse/RF-12839
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.3.1
> Environment: RichFaces 4.3.2-SNAPSHOT
> Metamer 4.3.2-SNAPSHOT
> JBoss Application Server: Weld Integration 7.1.3.Final-redhat-4
> JBoss AS 7.1.3.Final-redhat-4
> Java(TM) SE Runtime Environment 1.7.0_04-b20 @ Linux
> Chrome 25.0.1364.160 @ Linux x86_64
> Reporter: Pavol Pitonak
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.3.2
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/richTab/simple.xhtml
> # set oncomplete to "alert('complete')"
> # switch to tab 2 and back to tab 1
> result:
> * alert should be diplayed but isn't
> * tabs are correctly switched
> * worked fine in 4.2.3.Final
> * several attributes don't work - onbegin, onbeforedomupdate, oncomplete, data, execute, immediate, render, limitRender, status
> * affected components: tab, toggle panel item, accordion item
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (RF-12839) Toggle panels: ajax-related attributes do not work
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12839?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12839:
------------------------------------
The failure of the tab _execute_ attribute in 4.3.1.Final appears to be a client-side problem considering the following request headers, where the source of the request changed from _tab2_ to _tabPanel_ in 4.3.1.Final:
{code:title=Request headers in 4.2.3.Final}
myForm:myForm
myForm:tabPanel-value:tab2
myForm:inputText:abcd
javax.faces.ViewState:-1621502683831225105:4540128022449191033
javax.faces.source:myForm:tab2
javax.faces.partial.execute:myForm:tab2 @component
javax.faces.partial.render:@component
org.richfaces.ajax.component:myForm:tab2
myForm:tab2:myForm:tab2
AJAX:EVENTS_COUNT:1
javax.faces.partial.ajax:true
{code}
{code:title=Request headers in 4.3.1.Final}
myForm:myForm
myForm:tabPanel-value:tab2
myForm:inputText:abcd
javax.faces.ViewState:6815172795196689193:-1906887071623894429
javax.faces.source:myForm:tabPanel
javax.faces.partial.execute:myForm:tabPanel @component
javax.faces.partial.render:@component
org.richfaces.ajax.component:myForm:tabPanel
myForm:tabPanel:myForm:tabPanel
rfExt:null
AJAX:EVENTS_COUNT:1
javax.faces.partial.ajax:true
{code}
> Toggle panels: ajax-related attributes do not work
> --------------------------------------------------
>
> Key: RF-12839
> URL: https://issues.jboss.org/browse/RF-12839
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-output
> Affects Versions: 4.3.1
> Environment: RichFaces 4.3.2-SNAPSHOT
> Metamer 4.3.2-SNAPSHOT
> JBoss Application Server: Weld Integration 7.1.3.Final-redhat-4
> JBoss AS 7.1.3.Final-redhat-4
> Java(TM) SE Runtime Environment 1.7.0_04-b20 @ Linux
> Chrome 25.0.1364.160 @ Linux x86_64
> Reporter: Pavol Pitonak
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.3.2
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/richTab/simple.xhtml
> # set oncomplete to "alert('complete')"
> # switch to tab 2 and back to tab 1
> result:
> * alert should be diplayed but isn't
> * tabs are correctly switched
> * worked fine in 4.2.3.Final
> * several attributes don't work - onbegin, onbeforedomupdate, oncomplete, data, execute, immediate, render, limitRender, status
> * affected components: tab, toggle panel item, accordion item
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Cristian Cerb (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Cristian Cerb commented on RF-12897:
------------------------------------
Hi Lukas,
I have a number of concerns which, in my opinion, are not handled the best way neither by Sun, nor by RF. Would you have any time to chat on #richfaces IRC channel?
Thank you,
Cristian
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Assignee: Lukáš Fryč
> Priority: Critical
> Labels: richfaces
> Fix For: 4.3.2
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Cristian Cerb (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Cristian Cerb edited comment on RF-12897 at 4/19/13 12:25 PM:
--------------------------------------------------------------
Hi Lukas,
I have a number of concerns which, in my opinion, are not handled the best way neither by Mojarra, nor by RF. Would you have any time to chat on #richfaces IRC channel?
Thank you,
Cristian
was (Author: ccerb):
Hi Lukas,
I have a number of concerns which, in my opinion, are not handled the best way neither by Sun, nor by RF. Would you have any time to chat on #richfaces IRC channel?
Thank you,
Cristian
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Assignee: Lukáš Fryč
> Priority: Critical
> Labels: richfaces
> Fix For: 4.3.2
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-12897 at 4/19/13 11:42 AM:
-----------------------------------------------------------
The exception is swallowed here: https://github.com/richfaces/richfaces5/blob/master/framework/src/main/ja...
As I can see it, it was a try to improve Mojarra code in order to catch the exception, but Mojarra now fixed it in a much better way: catches just {{IOException}} and wraps it in {{FacesException}}. Non-checked exceptions are then propagated and caught higher in the tree, which is completely right.
We can do what Mojarra does here:
{code:title=Mojarra 2.1.19: http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai...
public VisitResult visit(VisitContext context, UIComponent comp) {
try {
if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
// RELEASE_PENDING handle immediate request(s)
// If the user requested an immediate request
// Make sure to set the immediate flag here.
comp.processDecodes(ctx);
} else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
comp.processValidators(ctx);
} else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
comp.processUpdates(ctx);
} else if (curPhase == PhaseId.RENDER_RESPONSE) {
PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
writer.startUpdate(comp.getClientId(ctx));
// do the default behavior...
comp.encodeAll(ctx);
writer.endUpdate();
} else {
throw new IllegalStateException("I18N: Unexpected " +
"PhaseId passed to " +
" PhaseAwareContextCallback: " +
curPhase.toString());
}
}
catch (IOException ex) {
if (LOGGER.isLoggable(Level.SEVERE)) {
LOGGER.severe(ex.toString());
}
if (LOGGER.isLoggable(Level.FINE)) {
LOGGER.log(Level.FINE,
ex.toString(),
ex);
}
throw new FacesException(ex);
}
// Once we visit a component, there is no need to visit
// its children, since processDecodes/Validators/Updates and
// encodeAll() already traverse the subtree. We return
// VisitResult.REJECT to supress the subtree visit.
return VisitResult.REJECT;
}
}
{code}
----
I propose to write test which should show that when renderer throws exception during encoding, the exception should be propagated to the client.
I guess that no update will be actually written in the partial-response, just view-state.
was (Author: lfryc):
The exception is swallowed here: https://github.com/richfaces/richfaces5/blob/master/framework/src/main/ja...
As I can see it, it was a try to improve Mojarra code in order to catch the exception, but Mojarra now fixed it in a much better way: catches just {{IOException}} and wraps it in {{FacesException}}. Non-checked exceptions are then propagated and caught higher in the tree, which is completely right.
We can do what Mojarra does here:
{code:title=Mojarra 2.1.19: http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai...
public VisitResult visit(VisitContext context, UIComponent comp) {
try {
if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
// RELEASE_PENDING handle immediate request(s)
// If the user requested an immediate request
// Make sure to set the immediate flag here.
comp.processDecodes(ctx);
} else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
comp.processValidators(ctx);
} else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
comp.processUpdates(ctx);
} else if (curPhase == PhaseId.RENDER_RESPONSE) {
PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
writer.startUpdate(comp.getClientId(ctx));
// do the default behavior...
comp.encodeAll(ctx);
writer.endUpdate();
} else {
throw new IllegalStateException("I18N: Unexpected " +
"PhaseId passed to " +
" PhaseAwareContextCallback: " +
curPhase.toString());
}
}
catch (IOException ex) {
if (LOGGER.isLoggable(Level.SEVERE)) {
LOGGER.severe(ex.toString());
}
if (LOGGER.isLoggable(Level.FINE)) {
LOGGER.log(Level.FINE,
ex.toString(),
ex);
}
throw new FacesException(ex);
}
// Once we visit a component, there is no need to visit
// its children, since processDecodes/Validators/Updates and
// encodeAll() already traverse the subtree. We return
// VisitResult.REJECT to supress the subtree visit.
return VisitResult.REJECT;
}
}
{code}
----
I propose to write test which should show that when renderer throws exception during encoding, the exception should be propagated to the client.
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Priority: Critical
> Labels: richfaces
> Fix For: 4.3.2
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč reassigned RF-12897:
-------------------------------
Assignee: Lukáš Fryč
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Assignee: Lukáš Fryč
> Priority: Critical
> Labels: richfaces
> Fix For: 4.3.2
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-12897 at 4/19/13 11:41 AM:
-----------------------------------------------------------
The exception is swallowed here: https://github.com/richfaces/richfaces5/blob/master/framework/src/main/ja...
As I can see it, it was a try to improve Mojarra code in order to catch the exception, but Mojarra now fixed it in a much better way: catches just {{IOException}} and wraps it in {{FacesException}}. Non-checked exceptions are then propagated and caught higher in the tree, which is completely right.
We can do what Mojarra does here:
{code:title=Mojarra 2.1.19: http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai...
public VisitResult visit(VisitContext context, UIComponent comp) {
try {
if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
// RELEASE_PENDING handle immediate request(s)
// If the user requested an immediate request
// Make sure to set the immediate flag here.
comp.processDecodes(ctx);
} else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
comp.processValidators(ctx);
} else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
comp.processUpdates(ctx);
} else if (curPhase == PhaseId.RENDER_RESPONSE) {
PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
writer.startUpdate(comp.getClientId(ctx));
// do the default behavior...
comp.encodeAll(ctx);
writer.endUpdate();
} else {
throw new IllegalStateException("I18N: Unexpected " +
"PhaseId passed to " +
" PhaseAwareContextCallback: " +
curPhase.toString());
}
}
catch (IOException ex) {
if (LOGGER.isLoggable(Level.SEVERE)) {
LOGGER.severe(ex.toString());
}
if (LOGGER.isLoggable(Level.FINE)) {
LOGGER.log(Level.FINE,
ex.toString(),
ex);
}
throw new FacesException(ex);
}
// Once we visit a component, there is no need to visit
// its children, since processDecodes/Validators/Updates and
// encodeAll() already traverse the subtree. We return
// VisitResult.REJECT to supress the subtree visit.
return VisitResult.REJECT;
}
}
{code}
----
I propose to write test which should show that when renderer throws exception during encoding, the exception should be propagated to the client.
was (Author: lfryc):
The exception is swallowed here: https://github.com/richfaces/richfaces5/blob/master/framework/src/main/ja...
As I can see it, it was try to improve Mojarra code in order to catch the exception, but Mojarra now fixed it in a much better way: catches just {{IOException}} and wraps it in {{FacesException}}. Non-checked exceptions are then propagated and caught higher in the tree, which is completely right.
We can do what Mojarra does here:
{code:title=Mojarra 2.1.19: http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai...
public VisitResult visit(VisitContext context, UIComponent comp) {
try {
if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
// RELEASE_PENDING handle immediate request(s)
// If the user requested an immediate request
// Make sure to set the immediate flag here.
comp.processDecodes(ctx);
} else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
comp.processValidators(ctx);
} else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
comp.processUpdates(ctx);
} else if (curPhase == PhaseId.RENDER_RESPONSE) {
PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
writer.startUpdate(comp.getClientId(ctx));
// do the default behavior...
comp.encodeAll(ctx);
writer.endUpdate();
} else {
throw new IllegalStateException("I18N: Unexpected " +
"PhaseId passed to " +
" PhaseAwareContextCallback: " +
curPhase.toString());
}
}
catch (IOException ex) {
if (LOGGER.isLoggable(Level.SEVERE)) {
LOGGER.severe(ex.toString());
}
if (LOGGER.isLoggable(Level.FINE)) {
LOGGER.log(Level.FINE,
ex.toString(),
ex);
}
throw new FacesException(ex);
}
// Once we visit a component, there is no need to visit
// its children, since processDecodes/Validators/Updates and
// encodeAll() already traverse the subtree. We return
// VisitResult.REJECT to supress the subtree visit.
return VisitResult.REJECT;
}
}
{code}
----
I propose to write test which should show that when renderer throws exception during encoding, the exception should be propagated to the client.
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Priority: Critical
> Labels: richfaces
> Fix For: 4.3.2
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-12897:
---------------------------------
The exception is swallowed here: https://github.com/richfaces/richfaces5/blob/master/framework/src/main/ja...
As I can see it, it was try to improve Mojarra code in order to catch the exception, but Mojarra now fixed it in a much better way: catches just {{IOException}} and wraps it in {{FacesException}}. Non-checked exceptions are then propagated and caught higher in the tree, which is completely right.
We can do what Mojarra does here:
{code:title=Mojarra 2.1.19: http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai...
public VisitResult visit(VisitContext context, UIComponent comp) {
try {
if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
// RELEASE_PENDING handle immediate request(s)
// If the user requested an immediate request
// Make sure to set the immediate flag here.
comp.processDecodes(ctx);
} else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
comp.processValidators(ctx);
} else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
comp.processUpdates(ctx);
} else if (curPhase == PhaseId.RENDER_RESPONSE) {
PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
writer.startUpdate(comp.getClientId(ctx));
// do the default behavior...
comp.encodeAll(ctx);
writer.endUpdate();
} else {
throw new IllegalStateException("I18N: Unexpected " +
"PhaseId passed to " +
" PhaseAwareContextCallback: " +
curPhase.toString());
}
}
catch (IOException ex) {
if (LOGGER.isLoggable(Level.SEVERE)) {
LOGGER.severe(ex.toString());
}
if (LOGGER.isLoggable(Level.FINE)) {
LOGGER.log(Level.FINE,
ex.toString(),
ex);
}
throw new FacesException(ex);
}
// Once we visit a component, there is no need to visit
// its children, since processDecodes/Validators/Updates and
// encodeAll() already traverse the subtree. We return
// VisitResult.REJECT to supress the subtree visit.
return VisitResult.REJECT;
}
}
{code}
----
I propose to write test which should show that when renderer throws exception during encoding, the exception should be propagated to the client.
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Priority: Critical
> Labels: richfaces
> Fix For: 4.3.2
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months