[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
1:03 a.m.
BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the
jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove firing
of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:09 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=all ]
Chris Rudd updated JBSEAM-1822:
-------------------------------
Description:
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ boolean hasError = true;
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
hasError = false;
+ }
+ finally
+ {
+ if( hasError )
+ facesContext.responseComplete();
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove firing
of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
was:
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove firing
of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ boolean hasError = true;
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
hasError = false;
+ }
+ finally
+ {
+ if( hasError )
+ facesContext.responseComplete();
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:09 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=all ]
Chris Rudd updated JBSEAM-1822:
-------------------------------
Description:
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove firing
of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
was:
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ boolean hasError = true;
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
hasError = false;
+ }
+ finally
+ {
+ if( hasError )
+ facesContext.responseComplete();
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove firing
of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:15 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=comments#action_12372889 ]
Chris Rudd commented on JBSEAM-1822:
------------------------------------
I guess that wont necissarially fix the core problem, as the SeamPhaseListener still doesn
have a way to know that there was an exception thrown.
perhaps the transaction side of it could be solved like this :
BaseSeamTest.java line 480 (BaseSeamTest.Request.run)
public String run() throws Exception
{
try
{
init();
beforeRequest();
setStandardJspVariables();
if ( emulateJsfLifecycle() )
{
saveConversationViewRoot();
}
afterRequest();
return conversationId;
}
finally
{
if (Contexts.isEventContextActive())
{
+ UserTransation transaction = Transaction.instance();
+ // If there is still ANY transaction active, roll it back.
+ if( ! transaction.isNoTransaction() )
+ transaction.rollback();
FacesLifecycle.endRequest(externalContext);
}
}
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:04 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Assigned: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=all ]
Gavin King reassigned JBSEAM-1822:
----------------------------------
Assignee: Gavin King
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Gavin King
Fix For: 2.0.0.CR1
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:04 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=all ]
Gavin King updated JBSEAM-1822:
-------------------------------
Fix Version/s: 2.0.0.CR1
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Gavin King
Fix For: 2.0.0.CR1
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:29 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=comments#action_12373918 ]
Sam Roberton commented on JBSEAM-1822:
--------------------------------------
Having tests which throw exceptions in a method called by emulateJsfLifecycle() also
appears to prevent the Session and contexts from being fully cleaned up correctly in the
BaseSeamTest.end() method.
BaseSeamTest.end() calls ServletLifecycle.endSession(), which calls
Lifecycle.endSession(), which complains (with an IllegalStateException) "Please end
the HttpSession via Seam.invalidateSession()" because one or both of the event and
application contexts is active. I can get around this to some extent by adding an
override end() method in (yet another) base class for my tests, and having that method
null out the application and event contexts reflectively (hack hack) if they're still
there. But while that solves the problem for that test case, other tests (which otherwise
pass) start failing. This is no doubt because my reflective killing of contexts not a
very sophisticated method of cleaning them up.
The root cause, so far as I can tell, is that the cleanup performed by
SeamPhaseListener.afterRender() (and potentially some other phase listener methods) is not
being performed.
Probably none of this is especially useful information, but I figured I should comment at
least to indicate that this doesn't just affect transactional behaviour, but is a
broader issue.
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Gavin King
Fix For: 2.0.0.CR1
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:36 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Assigned: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=all ]
Shane Bryzak reassigned JBSEAM-1822:
------------------------------------
Assignee: Shane Bryzak (was: Gavin King)
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.CR1
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:56 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=comments#action_12375815 ]
Shane Bryzak commented on JBSEAM-1822:
--------------------------------------
Chris - I've made the change you suggested to the run() method, rolling back the
transaction if there is one present. This isn't really my area of expertise so could
you please test this change and let me know if it fixes the problem. Sam - could you
please provide a test case that reproduces the IllegalStateException. I'll leave this
issue open for another day or so to confirm that the issue is indeed fixed.
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.CR1
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:04 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=comments#action_12375816 ]
Shane Bryzak commented on JBSEAM-1822:
--------------------------------------
Actually, I've just had to roll back the change because it's broken our unit
tests. For reference, here's the exception:
java.lang.RuntimeException: exception invoking: getTransaction
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:137)
at org.jboss.seam.Component.callComponentMethod(Component.java:2083)
at org.jboss.seam.Component.unwrap(Component.java:2109)
at org.jboss.seam.Component.getInstance(Component.java:1888)
at org.jboss.seam.Component.getInstance(Component.java:1853)
at org.jboss.seam.Component.getInstance(Component.java:1830)
at org.jboss.seam.Component.getInstance(Component.java:1825)
at org.jboss.seam.transaction.Transaction.instance(Transaction.java:36)
at org.jboss.seam.mock.BaseSeamTest$Request.run(BaseSeamTest.java:530)
at org.jboss.seam.test.DataModelTest.testDataModels(DataModelTest.java:39)
Caused by: javax.naming.NoInitialContextException: Need to specify class name in
environment or system property, or as an applet parameter, or in an application resource
file: java.naming.factory.initial
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:284)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at org.jboss.seam.transaction.Transaction.getUserTransaction(Transaction.java:79)
at org.jboss.seam.transaction.Transaction.createUTTransaction(Transaction.java:71)
at org.jboss.seam.transaction.Transaction.getTransaction(Transaction.java:44)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:23)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:127)
... 31 more
... Removed 26 stack frames
I'm not sure how to proceed from here, I'll see if Gavin can help out because he
wrote this stuff.
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.CR1
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:11 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=comments#action_12376024 ]
Sam Roberton commented on JBSEAM-1822:
--------------------------------------
Shane, I have seen your comments and am working on creating a test case (or set of test
cases) which cause(s) the IllegalStateException. That's proving harder than I would
have thought, unfortunately. I'm observing them in code for a decent-sized project
(I'm working in a branch trying to upgrade that codebase to Seam 2, still), but
I'm having trouble getting them to happen in a smaller scale test project.
Unfortunately, I doubt my employer would appreciate me sending you all our code so you
could reproduce it, and regardless, I doubt you'd want to wade through it.
I am still working on getting you a test case (probably test cases, plural, plus build
file, etc. --- the difficulty in reproduction makes me think it is heavily dependent on
concurrently executing tests), anyhow, but it might take me a bit longer to nail down the
exact circumstances that cause it.
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.CR1
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:54 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=comments#action_12376505 ]
Shane Bryzak commented on JBSEAM-1822:
--------------------------------------
Thanks Sam, if you could provide a test case that reproduces this it would be of great
help. I may need to push this issue back to the next release if it's not resolved in
the next couple of days.
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.CR1
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:40 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=all ]
Norman Richards updated JBSEAM-1822:
------------------------------------
Fix Version/s: 2.0.0.GA
(was: 2.0.0.CR1)
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.GA
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:21 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Closed: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=all ]
Shane Bryzak closed JBSEAM-1822.
--------------------------------
Resolution: Cannot Reproduce Bug
Closing this issue as I cannot reproduce it. If a test case can be provided that
reproduces the issue please reopen it.
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.GA
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:32 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=comments#action_12378508 ]
Sam Roberton commented on JBSEAM-1822:
--------------------------------------
Shane, sorry I haven't given you a test case yet --- unfortunately, other work
commitments are getting in the way of me paying real attention to this.
Nonetheless, even without a test case, isn't it clear from visual inspection of the
code that the BaseSeamTest$Request.emulateJsfLifecycle() method is incorrectly
implemented? It definitely doesn't handle exceptions raised by, say, the
invokeApplication() method, even though in order to test Seam's actual behaviour in
these circumstances, it needs to (at least) ensure that the phase listener's
'after phase' event is called.
In any case, I'll try a bit harder to free up some time to get you a decent test case
(or set of test cases), and once I do that, I'll re-open this issue.
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.GA
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:08 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=comments#action_12378717 ]
Sam Roberton commented on JBSEAM-1822:
--------------------------------------
The relevant excerpt from the JSF 1.2 spec is in section 11.3: "The JSF
implementation must guarantee that, if beforePhase() has been called on a particular
instance, then afterPhase() will also be called, regardless of any Exceptions that may
have been thrown during the actual execution of the lifecycle phase."
SeamPhaseListener relies on this behaviour: it relies on the fact that either
afterRender(FacesContext) or afterResponseComplete(FacesContext) is called in order to
clean up the contexts by calling Manager.instance().endRequest(Map) and
FacesLifecycle.endRequest(ExternalContext).
Therefore, since the phase listener 'after phase' methods will be called by a JSF
implementation, but are not called by BaseSeamTest, BaseSeamTest is not accurately
modelling (and so can't accurately be testing) the behaviour of the live application.
I'm about to attach a test case which highlights one problem which manifests itself
because of this: the conversation context is not flushed if the 'after phase'
event is not called, and so incorrect conversation behaviour can be observed from test
classes. No doubt this is not the only problem that's caused by not calling
'after phase' events, but it's the simplest one I can come up with a test case
for.
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.GA
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:19 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=comments#action_12378718 ]
Sam Roberton commented on JBSEAM-1822:
--------------------------------------
Turns out Jira won't let me re-open this issue, nor attach files for a test case, so
Shane, I'm emailing you the test case. Could you re-open this and attach the file,
please?
The test is very simple. There's a single component, StringHolder, which is
conversation-scoped. The test class makes three requests: (1) a non-faces request which
causes the component to be created by retrieving the value which is held; (2) a faces
request which updates the value held by the component, but which throws an exception in
invokeApplication(); and (3) a faces request which retrieves the value held by the
component again.
The third request causes a new StringHolder to be created, even though we're still in
the same conversation. I believe this is because the ServerConversationContext.flush()
method is not called for the second request, since that method is invoked (indirectly) by
SeamPhaseListener.afterRender(FacesContext).
Interestingly, even though a new StringHolder is created, the value retrieved from the
StringHolder by the third request is the value second by the second request. No idea how
that works...
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.GA
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:26 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=all ]
Shane Bryzak updated JBSEAM-1822:
---------------------------------
Attachment: StringHolder.java
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.GA
Attachments: SequentialTest.java, StringHolder.java
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:26 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Reopened: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=all ]
Shane Bryzak reopened JBSEAM-1822:
----------------------------------
Reopened.
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.GA
Attachments: SequentialTest.java, StringHolder.java
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:26 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=all ]
Shane Bryzak updated JBSEAM-1822:
---------------------------------
Attachment: SequentialTest.java
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.GA
Attachments: SequentialTest.java, StringHolder.java
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:36 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=all ]
Norman Richards updated JBSEAM-1822:
------------------------------------
Affects Version/s: 2.0.0.CR1
(was: 2.0.0.BETA1)
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.CR1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.GA
Attachments: SequentialTest.java, StringHolder.java
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:56 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=comments#action_12381934 ]
Shane Bryzak commented on JBSEAM-1822:
--------------------------------------
I've enforced that the afterPhase events for each phase always gets called by placing
them in a finally block, however your test case is still failing. It seems as though the
@Create method is being called more than once for the conversation-scoped component,
I'm still looking into it.
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.CR1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.GA
Attachments: SequentialTest.java, StringHolder.java
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:46 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Closed: (JBSEAM-1822) BaseSeamTest does not properly emulateJsfLifecycle does not handle phase listeners per the jsf 1.2 spec.
[ http://jira.jboss.com/jira/browse/JBSEAM-1822?page=all ]
Shane Bryzak closed JBSEAM-1822.
--------------------------------
Resolution: Done
Closing this, as I believe the test failures are unrelated to the original issue.
BaseSeamTest does not properly emulateJsfLifecycle does not handle
phase listeners per the jsf 1.2 spec.
--------------------------------------------------------------------------------------------------------
Key: JBSEAM-1822
URL: http://jira.jboss.com/jira/browse/JBSEAM-1822
Project: JBoss Seam
Issue Type: Bug
Components: Test Harness
Affects Versions: 2.0.0.CR1
Reporter: Chris Rudd
Assigned To: Shane Bryzak
Fix For: 2.0.0.GA
Attachments: SequentialTest.java, StringHolder.java
Under the 1.2 JSF spec, all phase listeners are called with the after phase events
reguarless of if an exception was thrown during the phase processing.
The resulting issue is that when Init.isTransactionMangementEnabled is true, and and an
exception (or an AssertionError) is thrown from within the phase method, the SeamPhase
listner does not get a chance to handle the condition and rollback the transaction. This
leaves the transaction open, and all further tests run for that class are now
"tainted" as there is a transaction running that will never be completed.
Wrapping code in the phase methods
(restoreViewPhase,applyRequestValuesPhase,processValidationsPhase,updateModelValuesPhase,invokeApplicationsPhase,
renderResponsePhase) like this will resolve the issue :
private void renderResponsePhase() throws Exception
{
phases.beforePhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ try
+ {
updateConversationId();
renderResponseBegun = true;
renderResponse();
renderResponseComplete = true;
facesContext.getApplication().getStateManager().saveView(facesContext);
updateConversationId();
+ }
+ finally
+ {
phases.afterPhase(new PhaseEvent(facesContext, PhaseId.RENDER_RESPONSE,
MockLifecycle.INSTANCE));
+ }
}
it may be cleaner to refactor the phase methods into PhaseExection classes. (remove
firing of phase events from the phase methods )
public class PhaseExecution {
private PhaseId phaseId;
public PhaseExecution(PhaseId phaseId)
{
this.phaseId = phaseId;
}
protected abstract void execute() throws Exception
public void run() throws Exception {
fireBefore();
try
{
execute();
}
finally
{
afterPhase();
}
}
protected void fireBefore()
{
phases.beforePhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
protected void fireAfter()
{
phases.afterPhase(new PhaseEvent(facesContext, phaseId,
MockLifecycle.INSTANCE));
}
}
final private PhaseExcecution RESTORE_VIEW_PHASE= new
PhaseExecution(PhaseId.RESTORE_VIEW) {
protected void execute() throws Exception {
restoreViewPhase();
}
};
final private PhaseExcecution RENDER_RESPONSE_PHASE= new
PhaseExecution(PhaseId.RENDER_RESPONSE) {
protected void execute() throws Exception {
renderResponsePhase();
}
};
...
/**
* @return true if a response was rendered
*/
private boolean emulateJsfLifecycle() throws Exception
{
RESTORE_VIEW_PHASE.run();
if ( !isGetRequest() && !skipToRender() )
{
APPLY_REQUEST_VALUES_PHASE.run();
if (!skipToRender())
{
PROCESS_VALIDATIONS_PHASE.run();
if ( !skipToRender() )
{
UPDATE_MODEL_VALUES_PHASE.run();
if ( !skipToRender() )
{
INVOKE_APPLICATION_PHASE.run();
}
}
}
}
if ( skipRender() )
{
// we really should look at redirect parameters here!
return false;
}
else
{
RENDER_RESPONSE_PHASE.run();
return true;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6291
days inactive
6349
days old
22 comments
5 participants
participants (5)
-
Chris Rudd (JIRA) -
Gavin King (JIRA)
-
Norman Richards (JIRA)
-
Sam Roberton (JIRA)
-
Shane Bryzak (JIRA)