[jira] Updated: (MYFACES-738) Exceptions thrown during processing of EL statements are not displayed with the underlying cause, and there is no log message.
[ http://issues.apache.org/jira/browse/MYFACES-738?page=all ]
Nikolay Petrov updated MYFACES-738:
---
Status: Patch Available (was: Open)
Exceptions thrown during processing of EL statements are not displayed with
the underlying cause, and there is no log message.
--
Key: MYFACES-738
URL: http://issues.apache.org/jira/browse/MYFACES-738
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Andrew Harris
Very difficult to identify exceptions that are thrown during processing of EL
statements, since all information is swallowed without logging.
org.apache.myfaces.el.PropertyResolverImpl.getProperty catches a Throwable
exception and creates a new EvaluationException
This is then caught by org.apache.myfaces.el.PropertyResolverImpl.getValue as
a RuntimeException and then throws a new EvaluationException.
This is in turn caught by the org.apache.myfaces.el.ValueBindingImpl.getValue
method Exception catch and another new EvaluationException is thown.
The error message on the UI is Exception:
javax.faces.el.EvaluationException: Cannot get value for expression
'#{erHandler.expectedReceipt.seqno}' which has lost all trace of the
underlying exception.
Would be better to have the information from the underlying exception in the
error message in the UI. If this is not practical, then a logged message
would greatly facilitate debugging.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1328) UISelectOne and UISelectMany fail with custom converter that returns java.lang.String from getAsObject() method.
[
http://issues.apache.org/jira/browse/MYFACES-1328?page=comments#action_12436990
]
Nikolay Petrov commented on MYFACES-1328:
-
I really don't see a reason to put conversion:
if(converter != null itemValue instanceof String)
{
itemValue = converter.getConvertedValue(context,
(String)itemValue);
}
in this case. A possible solution would be to remove conversion at all (as it
is within ri).
May be there is some special case to handle out. Can anybody made something up?
UISelectOne and UISelectMany fail with custom converter that returns
java.lang.String from getAsObject() method.
Key: MYFACES-1328
URL: http://issues.apache.org/jira/browse/MYFACES-1328
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.1.4-SNAPSHOT
Reporter: Alexey Maslov
Attachments: reproducer.zip
The problem seems to be in
javax.faces.component._SelectItemsUtil.matchValue(FacesContext context,
Object value, Iterator selectItemsIter, _ValueConverter converter) method.
Line 63-72:
Object itemValue = item.getValue();
if(converter != null itemValue instanceof String)
{
itemValue = converter.getConvertedValue(context,
(String)itemValue);
}
if (value==itemValue || value.equals(itemValue))
{
return true;
}
If item's value is java.lang.String then this code does duplicate conversion
making matchValue() return false and subsequently resulting in error in
calling method (validateValue() in javax.faces.component.UISelectOne and
javax.faces.component.UISelectMany).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-968) LifecycleImpl's restoreView throws NPE when viewId is null in a portlet context
[ http://issues.apache.org/jira/browse/MYFACES-968?page=all ]
Nikolay Petrov updated MYFACES-968:
---
Status: Patch Available (was: Open)
LifecycleImpl's restoreView throws NPE when viewId is null in a portlet
context
---
Key: MYFACES-968
URL: http://issues.apache.org/jira/browse/MYFACES-968
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.1, 1.1.0, 1.0.9m9
Reporter: Dave Brondsema
Priority: Minor
LifecycleImpl's restoreView throws exception when viewId is null and in a
portlet context
In restoreView:
if(viewId == null)
{
ExternalContext externalContext =
facesContext.getExternalContext();
if(!externalContext.getRequestServletPath().endsWith(/))
In a portlet context getRequestServletPath() returns null *by definition*.
Not only should we avoid the NPE, but we should do something appropriate for
portlets (return to the 'default-view')
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1418) javax.faces.validator - DoubleRangeValidator, LengthValidator, LongRangeValidator are very similar, refactor common behaviour
javax.faces.validator - DoubleRangeValidator, LengthValidator, LongRangeValidator are very similar, refactor common behaviour - Key: MYFACES-1418 URL: http://issues.apache.org/jira/browse/MYFACES-1418 Project: MyFaces Core Issue Type: Improvement Components: JSR-127 Affects Versions: 1.1.4 Reporter: Nikolay Petrov Fix For: 1.1.5-SNAPSHOT The 3 classes are very similar to each other except the type of minimum and maximum (and value of course). Therefore I'll suggest extracting the common behaviour in common parent class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1418) javax.faces.validator - DoubleRangeValidator, LengthValidator, LongRangeValidator are very similar, refactor common behaviour
[ http://issues.apache.org/jira/browse/MYFACES-1418?page=all ] Nikolay Petrov updated MYFACES-1418: Status: Patch Available (was: Open) javax.faces.validator - DoubleRangeValidator, LengthValidator, LongRangeValidator are very similar, refactor common behaviour - Key: MYFACES-1418 URL: http://issues.apache.org/jira/browse/MYFACES-1418 Project: MyFaces Core Issue Type: Improvement Components: JSR-127 Affects Versions: 1.1.4 Reporter: Nikolay Petrov Fix For: 1.1.5-SNAPSHOT Attachments: validator.patch The 3 classes are very similar to each other except the type of minimum and maximum (and value of course). Therefore I'll suggest extracting the common behaviour in common parent class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1419) javax.faces.convert - refactor common behaviour + DateTimeConverter changes
javax.faces.convert - refactor common behaviour + DateTimeConverter changes --- Key: MYFACES-1419 URL: http://issues.apache.org/jira/browse/MYFACES-1419 Project: MyFaces Core Issue Type: Improvement Components: JSR-127 Affects Versions: 1.1.4 Reporter: Nikolay Petrov Priority: Minor Fix For: 1.1.5-SNAPSHOT All available converters look very similar. Extract the common behavior in base class. Also DateTimeConverter can be migrated to work with type safe enums for style and type properties. There are comments in source like //TODO: validate timeStyle. According to java doc of DateTimeConverter on sun there should not have validation. The validation of these will be performed when asString/asObject methods are called. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1419) javax.faces.convert - refactor common behaviour + DateTimeConverter changes
[ http://issues.apache.org/jira/browse/MYFACES-1419?page=all ] Nikolay Petrov updated MYFACES-1419: Status: Patch Available (was: Open) javax.faces.convert - refactor common behaviour + DateTimeConverter changes --- Key: MYFACES-1419 URL: http://issues.apache.org/jira/browse/MYFACES-1419 Project: MyFaces Core Issue Type: Improvement Components: JSR-127 Affects Versions: 1.1.4 Reporter: Nikolay Petrov Priority: Minor Fix For: 1.1.5-SNAPSHOT All available converters look very similar. Extract the common behavior in base class. Also DateTimeConverter can be migrated to work with type safe enums for style and type properties. There are comments in source like //TODO: validate timeStyle. According to java doc of DateTimeConverter on sun there should not have validation. The validation of these will be performed when asString/asObject methods are called. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1409) incorrect behavior after RESTORE_VIEW responseComplete
[
http://issues.apache.org/jira/browse/MYFACES-1409?page=comments#action_12436541
]
Nikolay Petrov commented on MYFACES-1409:
-
After calling listeners in restore view phase(and every other) there is the
following snippet:
...
if (isResponseComplete(facesContext, executor.getPhase(), false)
|| shouldRenderResponse(facesContext,
executor.getPhase(), false)) {
// since this phase is completed we don't need to return right
away even if the response is completed
skipFurtherProcessing = true;
}
if (!skipFurtherProcessing log.isTraceEnabled()) {
log.trace(exiting + executor.getPhase() + in +
LifecycleImpl.class.getName());
}
return skipFurtherProcessing;
...
This breaks the phase execution cycle and returns back to the servlet, where
render of the Lifecycle is executed. And the method starts with:
...
public void render(FacesContext facesContext) throws FacesException {
// if the response is complete we should not be invoking the phase
listeners
if(isResponseComplete(facesContext, renderExecutor.getPhase(), true)) {
return;
}
...
This means that render response phase is actually not executed. So the next
thing on request comming through jsf servlet would be restore view phase again.
Is that correct?
incorrect behavior after RESTORE_VIEW responseComplete
--
Key: MYFACES-1409
URL: http://issues.apache.org/jira/browse/MYFACES-1409
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.5-SNAPSHOT
Environment: Windows XP, apache-tomcat-5.5.17
Reporter: Leonid Mikhailov
Fix For: 1.1.5-SNAPSHOT
The following behavior appears to be incorrect in myfaces implementation of
JSF.
After FacesContext.responseComplete is issued in the afterPhase method of
the PhaseListener at the RESTORE_VIEW phase, myfaces implementation skips to
RENDER_RESPONSE phase. This appears to be incorrect, as following a call to
FacesContext.responseComplete JSF implementation should exit JSF lifecycle
completely, i.e. the next phase of the lifecycle should be again
RESTORE_VIEW.
This problem can be observed when running Sun's Progress Bar with JSF and
AJAX Sample with myfaces libraries on Tomcat.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1411) Lifecycle phase executions repetitions
Lifecycle phase executions repetitions
--
Key: MYFACES-1411
URL: http://issues.apache.org/jira/browse/MYFACES-1411
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-127
Affects Versions: 1.1.4
Reporter: Nikolay Petrov
Priority: Minor
Fix For: 1.1.5-SNAPSHOT
Every phase in LifecycleImpl looks like:
private boolean applyRequestValues(FacesContext facesContext,
PhaseListenerManager phaseListenerMgr)
throws FacesException
{
boolean skipFurtherProcessing = false;
if (log.isTraceEnabled()) log.trace(entering applyRequestValues in +
LifecycleImpl.class.getName());
try {
phaseListenerMgr.informPhaseListenersBefore(PhaseId.APPLY_REQUEST_VALUES);
if(isResponseComplete(facesContext, applyRequestValues, true))
{
// have to return right away
return true;
}
if(shouldRenderResponse(facesContext, applyRequestValues, true))
{
skipFurtherProcessing = true;
}
facesContext.getViewRoot().processDecodes(facesContext);
} finally {
phaseListenerMgr.informPhaseListenersAfter(PhaseId.APPLY_REQUEST_VALUES);
}
if (isResponseComplete(facesContext, applyRequestValues, false)
|| shouldRenderResponse(facesContext,
applyRequestValues, false))
{
// since this phase is completed we don't need to
return right away even if the response is completed
skipFurtherProcessing = true;
}
if (!skipFurtherProcessing log.isTraceEnabled())
log.trace(exiting applyRequestValues in
+ LifecycleImpl.class.getName());
return skipFurtherProcessing;
}
And that is repeated as many times as phases are. The fix will be to extract
the common behavior in a method, that receives one additional parameter -
PhaseExecutor and delegate to it the real execution.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1411) Lifecycle phase executions repetitions
[ http://issues.apache.org/jira/browse/MYFACES-1411?page=all ]
Nikolay Petrov updated MYFACES-1411:
Status: Patch Available (was: Open)
Lifecycle phase executions repetitions
--
Key: MYFACES-1411
URL: http://issues.apache.org/jira/browse/MYFACES-1411
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-127
Affects Versions: 1.1.4
Reporter: Nikolay Petrov
Priority: Minor
Fix For: 1.1.5-SNAPSHOT
Every phase in LifecycleImpl looks like:
private boolean applyRequestValues(FacesContext facesContext,
PhaseListenerManager phaseListenerMgr)
throws FacesException
{
boolean skipFurtherProcessing = false;
if (log.isTraceEnabled()) log.trace(entering applyRequestValues in
+ LifecycleImpl.class.getName());
try {
phaseListenerMgr.informPhaseListenersBefore(PhaseId.APPLY_REQUEST_VALUES);
if(isResponseComplete(facesContext, applyRequestValues, true))
{
// have to return right away
return true;
}
if(shouldRenderResponse(facesContext, applyRequestValues, true))
{
skipFurtherProcessing = true;
}
facesContext.getViewRoot().processDecodes(facesContext);
} finally {
phaseListenerMgr.informPhaseListenersAfter(PhaseId.APPLY_REQUEST_VALUES);
}
if (isResponseComplete(facesContext, applyRequestValues, false)
|| shouldRenderResponse(facesContext,
applyRequestValues, false))
{
// since this phase is completed we don't need to
return right away even if the response is completed
skipFurtherProcessing = true;
}
if (!skipFurtherProcessing log.isTraceEnabled())
log.trace(exiting applyRequestValues in
+ LifecycleImpl.class.getName());
return skipFurtherProcessing;
}
And that is repeated as many times as phases are. The fix will be to extract
the common behavior in a method, that receives one additional parameter -
PhaseExecutor and delegate to it the real execution.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1412) Restore view phase does not conforms specification
[ http://issues.apache.org/jira/browse/MYFACES-1412?page=all ]
Nikolay Petrov updated MYFACES-1412:
Status: Patch Available (was: Open)
Restore view phase does not conforms specification
--
Key: MYFACES-1412
URL: http://issues.apache.org/jira/browse/MYFACES-1412
Project: MyFaces Core
Issue Type: Bug
Components: JSR-127
Affects Versions: 1.1.4
Reporter: Nikolay Petrov
Fix For: 1.1.5-SNAPSHOT
Attachments: RestoreViewExecutor.java
JSF 1.1 spec, section 2.2.1 says:
-Examine the FacesContext instance for the current request. If it already
contains a UIViewRoot:
--Set the locale on this UIViewRoot to the value returned by the
getRequestLocale() method on the ExternalContext for this request.
--For each component in the component tree, determine if a ValueBinding for
binding is present. If so, call the setValue() method on this
ValueBinding, passing the component instance on which it was found.
--Take no further action during this phase.
As I was looking at restore view phase implementation there was no such
behaviour implemented. This should be implemented as:
if(facesContext.getViewRoot() != null) {
facesContext.getViewRoot().setLocale(facesContext.getExternalContext().getRequestLocale());
RestoreStateUtils.recursivelyHandleComponentReferencesAndSetValid(facesContext,
facesContext.getViewRoot());
return false;
}
At least if understand the code properly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1412) Restore view phase does not conforms specification
Restore view phase does not conforms specification
--
Key: MYFACES-1412
URL: http://issues.apache.org/jira/browse/MYFACES-1412
Project: MyFaces Core
Issue Type: Bug
Components: JSR-127
Affects Versions: 1.1.4
Reporter: Nikolay Petrov
Fix For: 1.1.5-SNAPSHOT
Attachments: RestoreViewExecutor.java
JSF 1.1 spec, section 2.2.1 says:
-Examine the FacesContext instance for the current request. If it already
contains a UIViewRoot:
--Set the locale on this UIViewRoot to the value returned by the
getRequestLocale() method on the ExternalContext for this request.
--For each component in the component tree, determine if a ValueBinding for
binding is present. If so, call the setValue() method on this
ValueBinding, passing the component instance on which it was found.
--Take no further action during this phase.
As I was looking at restore view phase implementation there was no such
behaviour implemented. This should be implemented as:
if(facesContext.getViewRoot() != null) {
facesContext.getViewRoot().setLocale(facesContext.getExternalContext().getRequestLocale());
RestoreStateUtils.recursivelyHandleComponentReferencesAndSetValid(facesContext,
facesContext.getViewRoot());
return false;
}
At least if understand the code properly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1389) Impossible to escape {, } characters in parameterized messages.
[
http://issues.apache.org/jira/browse/MYFACES-1389?page=comments#action_12436223
]
Nikolay Petrov commented on MYFACES-1389:
-
FacesUtil.substituteParams is now in MessageUtils (I think). The one in message
utils is using MessageFormat internally. There is written:
Within a String, '' represents a single quote. A QuotedString can contain
arbitrary characters except single quotes; the surrounding single quotes are
removed. An UnquotedString can contain arbitrary characters except single
quotes and left curly brackets. Thus, a string that should result in the
formatted message '{0}' can be written as '''{'0}'' or '''{0}'''.
Is that fixes the thing?
Impossible to escape {, } characters in parameterized messages.
---
Key: MYFACES-1389
URL: http://issues.apache.org/jira/browse/MYFACES-1389
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.1.3
Reporter: Guy Bashan
Priority: Minor
It seems like using the {, } characters in messages (in resource bundles)
is impossible (Unless it is used for params: {0}, {1} etc'). The
FacesUtil.subtituteParams seems to be throwing an exception. I tried escaping
the characters by using \{ but it still not working.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
