[jira] [Commented] (MYFACES-3902) jsf.js: error handling output improvement
[
https://issues.apache.org/jira/browse/MYFACES-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040516#comment-14040516
]
Werner Punz commented on MYFACES-3902:
--
Thanks for reporting the issue, I will work on it sometime this week, as my
time permits.
jsf.js: error handling output improvement
-
Key: MYFACES-3902
URL: https://issues.apache.org/jira/browse/MYFACES-3902
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.2.3
Environment: Snapshot code 2.2.3 from trunk + Icefaces 4/Primefaces 4
Firefox =18
Reporter: Krashan Brahmanjara
Myfaces core do not show real javascipt errors.
In _Dom.js there is a catch block in rows 192-203.
Unofortunately I see two errors
- Icefaces js has exceptions without message and description a message is
directly a 'e' object. So an error 'invalid property' is printed to console
- development mode is ignored by this catch block, in reverse order checking
too because jsf.ajax.getProjectStage() is not initialized
Workaround - because development mode is recognized we can only show an alert
{noformat}
} catch (e) {
/*
if(window.console window.console.error) {
//not sure if we
//should use our standard
//error mechanisms here
//because in the head appendix
//method only a console
//error would be raised as well
if (e.message) {
window.console.error(e.message);
} else {
if (e.description) {
window.console.error(e.description);
} else {
window.console.error(e);
}
}
}
if(jsf.ajax.getProjectStage() === Development) {
*/
if (e.message) {
alert(Error in evaluated javascript:+
(e.message));
} else {
if (e.description) {
alert(Error in evaluated
javascript:+ (e.description));
} else {
alert(Error in evaluated
javascript:+ (e));
}
}
/*
}
*/
} finally {
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MYFACES-3902) jsf.js: error handling output improvement
[
https://issues.apache.org/jira/browse/MYFACES-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040562#comment-14040562
]
Werner Punz commented on MYFACES-3902:
--
There were actually two problems a) we have to have a fallback for a pure e
object as parameter, secondly there was a wrong call to getProjectStage both
will be fixed asap
jsf.js: error handling output improvement
-
Key: MYFACES-3902
URL: https://issues.apache.org/jira/browse/MYFACES-3902
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.2.3
Environment: Snapshot code 2.2.3 from trunk + Icefaces 4/Primefaces 4
Firefox =18
Reporter: Krashan Brahmanjara
Myfaces core do not show real javascipt errors.
In _Dom.js there is a catch block in rows 192-203.
Unofortunately I see two errors
- Icefaces js has exceptions without message and description a message is
directly a 'e' object. So an error 'invalid property' is printed to console
- development mode is ignored by this catch block, in reverse order checking
too because jsf.ajax.getProjectStage() is not initialized
Workaround - because development mode is recognized we can only show an alert
{noformat}
} catch (e) {
/*
if(window.console window.console.error) {
//not sure if we
//should use our standard
//error mechanisms here
//because in the head appendix
//method only a console
//error would be raised as well
if (e.message) {
window.console.error(e.message);
} else {
if (e.description) {
window.console.error(e.description);
} else {
window.console.error(e);
}
}
}
if(jsf.ajax.getProjectStage() === Development) {
*/
if (e.message) {
alert(Error in evaluated javascript:+
(e.message));
} else {
if (e.description) {
alert(Error in evaluated
javascript:+ (e.description));
} else {
alert(Error in evaluated
javascript:+ (e));
}
}
/*
}
*/
} finally {
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TRINIDAD-2485) Some attribute behaviors in tr:validateDateRestriction donot match their documentation
Ashwin Prabhu created TRINIDAD-2485:
---
Summary: Some attribute behaviors in tr:validateDateRestriction
donot match their documentation
Key: TRINIDAD-2485
URL: https://issues.apache.org/jira/browse/TRINIDAD-2485
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.1.0-core
Reporter: Ashwin Prabhu
There are several issues in tr:validateDateRestriction. Here's a attribute-wise
list of problems which need to be fixed:
Attribute: invalidDays
The start and end dates passed into the method getDateList of DateListProvider
needs to be 24 hour wide. Currently the same date is passed for start and end
range, defeating the purpose of haveing 2 parameters. The current arrangement
works only if DateListProvider strictly goes by the date part and ignores the
time component in the start and end range.
The documentation of DateListProvider has this:
rangeStart - The start of the range for which dates are being requested.
rangeEnd - The end of the range for which dates are being requested.
Although not literallly mentioned, the implicit messaging of the parmater
description suggests the time part of the date range cannot be ignored.
Attribute: messageDetailInvalidDaysOfWeek
The documentation of message parameters states this:
{0} the label that identifies the component
{1} value entered by the user
{2} the invalid weekday
Currently the values passed as 3rd parameter ({2}) on the client contains a
list of all the days of the week, but for the user selected week. This behavior
is wrong as per the documentation. To see this behavior in acion please visit
http://example.irian.at/trinidad-demo/faces/convertValidate/dateRestrictionValidate.jspx
and select any monday in the 3rd input Date. You will see a error message
Enter a date that is on one of the following days: Tuesday, Wednesday,
Thursday, Friday, Saturday, Sunday. Here both the message and the week-day
parameters are worng. On the server however this is done as per the
documentation, but the passed in weekday is not localized, but picked up from
the internal _dayMap map containing the week days as sun, monsat .
To summarize,
The client validator needs to pass in parameters as per the documentation.
The server validator needs to localize the substituted week days.
THe message bundle string is currently Enter a date that falls on one of the
following days: {0} also needs to be changed to match the intention in the tag
document.
Attribute: messageDetailInvalidMonths
The documentation of message parameters states this:
{0} the label that identifies the component
{1} value entered by the user
{2} the invalid month
Currently the values passed as 3rd parameter ({2}) on the client contains a
list of all the months of the year, but for the user selected month. This
behavior is wrong as per the documentation. To see this behavior in acion
please visit
http://example.irian.at/trinidad-demo/faces/convertValidate/dateRestrictionValidate.jspx
and select any day in November in the 2rd input Date. You will see a error
message November/December dates are not allowed here!
Enter a date in one of the following months: January, February, March, April,
May, June, July, August, September, October. Here both the message and the
month parameters are worng. On the server however this is done as per the
documentation, but the passed in month is not localized, but picked up from the
internal _monthMap map containing the months as jan, febdec .
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MYFACES-3902) jsf.js: error handling output improvement
[
https://issues.apache.org/jira/browse/MYFACES-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040577#comment-14040577
]
Werner Punz commented on MYFACES-3902:
--
Fixed
jsf.js: error handling output improvement
-
Key: MYFACES-3902
URL: https://issues.apache.org/jira/browse/MYFACES-3902
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.2.3
Environment: Snapshot code 2.2.3 from trunk + Icefaces 4/Primefaces 4
Firefox =18
Reporter: Krashan Brahmanjara
Fix For: 2.0.22-SNAPSHOT, 2.1.16-SNAPSHOT, 2.2.4-SNAPSHOT
Myfaces core do not show real javascipt errors.
In _Dom.js there is a catch block in rows 192-203.
Unofortunately I see two errors
- Icefaces js has exceptions without message and description a message is
directly a 'e' object. So an error 'invalid property' is printed to console
- development mode is ignored by this catch block, in reverse order checking
too because jsf.ajax.getProjectStage() is not initialized
Workaround - because development mode is recognized we can only show an alert
{noformat}
} catch (e) {
/*
if(window.console window.console.error) {
//not sure if we
//should use our standard
//error mechanisms here
//because in the head appendix
//method only a console
//error would be raised as well
if (e.message) {
window.console.error(e.message);
} else {
if (e.description) {
window.console.error(e.description);
} else {
window.console.error(e);
}
}
}
if(jsf.ajax.getProjectStage() === Development) {
*/
if (e.message) {
alert(Error in evaluated javascript:+
(e.message));
} else {
if (e.description) {
alert(Error in evaluated
javascript:+ (e.description));
} else {
alert(Error in evaluated
javascript:+ (e));
}
}
/*
}
*/
} finally {
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (MYFACES-3902) jsf.js: error handling output improvement
[
https://issues.apache.org/jira/browse/MYFACES-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-3902.
--
Resolution: Fixed
Fix Version/s: 2.2.4-SNAPSHOT
2.1.16-SNAPSHOT
2.0.22-SNAPSHOT
jsf.js: error handling output improvement
-
Key: MYFACES-3902
URL: https://issues.apache.org/jira/browse/MYFACES-3902
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.2.3
Environment: Snapshot code 2.2.3 from trunk + Icefaces 4/Primefaces 4
Firefox =18
Reporter: Krashan Brahmanjara
Fix For: 2.0.22-SNAPSHOT, 2.1.16-SNAPSHOT, 2.2.4-SNAPSHOT
Myfaces core do not show real javascipt errors.
In _Dom.js there is a catch block in rows 192-203.
Unofortunately I see two errors
- Icefaces js has exceptions without message and description a message is
directly a 'e' object. So an error 'invalid property' is printed to console
- development mode is ignored by this catch block, in reverse order checking
too because jsf.ajax.getProjectStage() is not initialized
Workaround - because development mode is recognized we can only show an alert
{noformat}
} catch (e) {
/*
if(window.console window.console.error) {
//not sure if we
//should use our standard
//error mechanisms here
//because in the head appendix
//method only a console
//error would be raised as well
if (e.message) {
window.console.error(e.message);
} else {
if (e.description) {
window.console.error(e.description);
} else {
window.console.error(e);
}
}
}
if(jsf.ajax.getProjectStage() === Development) {
*/
if (e.message) {
alert(Error in evaluated javascript:+
(e.message));
} else {
if (e.description) {
alert(Error in evaluated
javascript:+ (e.description));
} else {
alert(Error in evaluated
javascript:+ (e));
}
}
/*
}
*/
} finally {
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TRINIDAD-2485) Some attribute behaviors in tr:validateDateRestriction donot match their documentation
[
https://issues.apache.org/jira/browse/TRINIDAD-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashwin Prabhu updated TRINIDAD-2485:
Status: Patch Available (was: Open)
Some attribute behaviors in tr:validateDateRestriction donot match their
documentation
--
Key: TRINIDAD-2485
URL: https://issues.apache.org/jira/browse/TRINIDAD-2485
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.1.0-core
Reporter: Ashwin Prabhu
Original Estimate: 24h
Remaining Estimate: 24h
There are several issues in tr:validateDateRestriction. Here's a
attribute-wise list of problems which need to be fixed:
Attribute: invalidDays
The start and end dates passed into the method getDateList of
DateListProvider needs to be 24 hour wide. Currently the same date is passed
for start and end range, defeating the purpose of haveing 2 parameters. The
current arrangement works only if DateListProvider strictly goes by the date
part and ignores the time component in the start and end range.
The documentation of DateListProvider has this:
rangeStart - The start of the range for which dates are being requested.
rangeEnd - The end of the range for which dates are being requested.
Although not literallly mentioned, the implicit messaging of the parmater
description suggests the time part of the date range cannot be ignored.
Attribute: messageDetailInvalidDaysOfWeek
The documentation of message parameters states this:
{0} the label that identifies the component
{1} value entered by the user
{2} the invalid weekday
Currently the values passed as 3rd parameter ({2}) on the client contains a
list of all the days of the week, but for the user selected week. This
behavior is wrong as per the documentation. To see this behavior in acion
please visit
http://example.irian.at/trinidad-demo/faces/convertValidate/dateRestrictionValidate.jspx
and select any monday in the 3rd input Date. You will see a error message
Enter a date that is on one of the following days: Tuesday, Wednesday,
Thursday, Friday, Saturday, Sunday. Here both the message and the week-day
parameters are worng. On the server however this is done as per the
documentation, but the passed in weekday is not localized, but picked up from
the internal _dayMap map containing the week days as sun, monsat .
To summarize,
The client validator needs to pass in parameters as per the documentation.
The server validator needs to localize the substituted week days.
THe message bundle string is currently Enter a date that falls on one of the
following days: {0} also needs to be changed to match the intention in the
tag document.
Attribute: messageDetailInvalidMonths
The documentation of message parameters states this:
{0} the label that identifies the component
{1} value entered by the user
{2} the invalid month
Currently the values passed as 3rd parameter ({2}) on the client contains a
list of all the months of the year, but for the user selected month. This
behavior is wrong as per the documentation. To see this behavior in acion
please visit
http://example.irian.at/trinidad-demo/faces/convertValidate/dateRestrictionValidate.jspx
and select any day in November in the 2rd input Date. You will see a error
message November/December dates are not allowed here!
Enter a date in one of the following months: January, February, March, April,
May, June, July, August, September, October. Here both the message and the
month parameters are worng. On the server however this is done as per the
documentation, but the passed in month is not localized, but picked up from
the internal _monthMap map containing the months as jan, febdec .
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TRINIDAD-2484) Threadsafety issue in SkinStyleProvider leading to missing styles and distorted ui
[ https://issues.apache.org/jira/browse/TRINIDAD-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Schwartz resolved TRINIDAD-2484. - Resolution: Fixed Fix Version/s: 2.1.1-core Assignee: Andy Schwartz Committed in r1604869. Thanks for the fix, Prakash! Threadsafety issue in SkinStyleProvider leading to missing styles and distorted ui -- Key: TRINIDAD-2484 URL: https://issues.apache.org/jira/browse/TRINIDAD-2484 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Prakash Udupa Assignee: Andy Schwartz Fix For: 2.1.1-core Attachments: TRINIDAD-2484-trunk.patch Original Estimate: 24h Remaining Estimate: 24h We have seen that soon after server start, when there are almost concurrent requests from IE, in random occurrences, there will be only one link encoded in the HTML, while there are two css files generated. Consequently, styles for some components in the page could go missing, ending up in distorted UI in certain sections of the rendered page. We suspect the cause to be a thread safety issue in SkinStyleProvider implementation where we construct style providers and save it in map keyed by skin and the directory path of the css. The issue is in _getProviders() implementation, where the variable _sSharedProviders is not accessed in threadsafe manner. This leads to possibility of the providers map being overwritten. This further leads to constructing two SkinStyleProviders for the same skin. While one request could use one provider (P1) that is in process of writing out one css file with the second one pending, there could be other request that ends up using a different provider (P2) that would see a single file written, and end up adding single URI in its Entry map. All requests later could end up using P2 and sufferring from only one link being rendered, while there are two stylesheets actually generated. Proposed fix is to eliminate _sSharedProviders, and instead use the application scoped concurrent map hanging off of request scope to store the provider map. We can then leverage on the putIfAbsent in there to ensure there is only one copy of providers map for an application. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2486) SELECTOR OF KIND IMG[SRC*=/ADF/IMAGES/T.GIF] BREAKS IF SKIN COMPRESSION IS ON
Anand V Nath created TRINIDAD-2486: -- Summary: SELECTOR OF KIND IMG[SRC*=/ADF/IMAGES/T.GIF] BREAKS IF SKIN COMPRESSION IS ON Key: TRINIDAD-2486 URL: https://issues.apache.org/jira/browse/TRINIDAD-2486 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath With selector of kind X[attr = foo.gif] is used and skin compression is on, the generated css is malformed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TRINIDAD-2486) SELECTOR OF KIND IMG[SRC*=/ADF/IMAGES/T.GIF] BREAKS IF SKIN COMPRESSION IS ON
[ https://issues.apache.org/jira/browse/TRINIDAD-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand V Nath updated TRINIDAD-2486: --- Status: Patch Available (was: Open) SELECTOR OF KIND IMG[SRC*=/ADF/IMAGES/T.GIF] BREAKS IF SKIN COMPRESSION IS ON --- Key: TRINIDAD-2486 URL: https://issues.apache.org/jira/browse/TRINIDAD-2486 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Attachments: jira-2486-on-trunk.patch With selector of kind X[attr = foo.gif] is used and skin compression is on, the generated css is malformed. -- This message was sent by Atlassian JIRA (v6.2#6252)
