[ANNOUNCE] Apache MyFaces Tobago 1.0.33
The Apache MyFaces team is pleased to announce the release of Apache MyFaces Tobago 1.0.33. Apache MyFaces Tobago is a renderkit for JSF and runs with MyFaces Core. Please check the release notes at http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12315586 for a full list of the changes in version 1.0.33. For more information about Apache Tobago, please visit http://myfaces.apache.org/tobago/. Have fun, -The MyFaces team
[VOTE] Release of Trinidad 2.0.0 Beta 2 (Try 2)
Hey Everyone, Okay, I have checked in code to address TRINIDAD-2037 which was the issue raised by Matthias in the previous vote[1]. The artifacts have been regenerated and Matthias has tested the fix and it works. This is still a beta release so there are still a few open bugs, but all of the unit tests pass and this beta has undergone some considerable testing since the last release. Therefore I would like to ask for a re-vote on this release. All of the following should be ready for review: * The generated repository and assembly artifacts[2] * The generated source archive[3] * The updated svn repository[4] Please review the artifacts and vote according to the following: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1]http://www.mail-archive.com/dev@myfaces.apache.org/msg51466.html [2] https://repository.apache.org/content/repositories/orgapachemyfaces-015/ [3] https://repository.apache.org/content/repositories/orgapachemyfaces-015/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-2/trinidad-2.0.0-beta-2-source-release.zip [4] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.0-beta-2
Re: [VOTE] Release of Trinidad 2.0.0 Beta 2 (Try 2)
+1 On 02/16/2011 07:48 AM, Scott O'Bryan wrote: Hey Everyone, Okay, I have checked in code to address TRINIDAD-2037 which was the issue raised by Matthias in the previous vote[1]. The artifacts have been regenerated and Matthias has tested the fix and it works. This is still a beta release so there are still a few open bugs, but all of the unit tests pass and this beta has undergone some considerable testing since the last release. Therefore I would like to ask for a re-vote on this release. All of the following should be ready for review: * The generated repository and assembly artifacts[2] * The generated source archive[3] * The updated svn repository[4] Please review the artifacts and vote according to the following: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1]http://www.mail-archive.com/dev@myfaces.apache.org/msg51466.html [2] https://repository.apache.org/content/repositories/orgapachemyfaces-015/ [3] https://repository.apache.org/content/repositories/orgapachemyfaces-015/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-2/trinidad-2.0.0-beta-2-source-release.zip [4] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.0-beta-2
Re: [VOTE] Release of Trinidad 2.0.0 Beta 2 (Try 2)
+1 On 2/16/2011 9:48 AM, Scott O'Bryan wrote: Hey Everyone, Okay, I have checked in code to address TRINIDAD-2037 which was the issue raised by Matthias in the previous vote[1]. The artifacts have been regenerated and Matthias has tested the fix and it works. This is still a beta release so there are still a few open bugs, but all of the unit tests pass and this beta has undergone some considerable testing since the last release. Therefore I would like to ask for a re-vote on this release. All of the following should be ready for review: * The generated repository and assembly artifacts[2] * The generated source archive[3] * The updated svn repository[4] Please review the artifacts and vote according to the following: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg51466.html [2] https://repository.apache.org/content/repositories/orgapachemyfaces-015/ [3] https://repository.apache.org/content/repositories/orgapachemyfaces-015/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-2/trinidad-2.0.0-beta-2-source-release.zip [4] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.0-beta-2
Re: [VOTE] Release of Trinidad 2.0.0 Beta 2 (Try 2)
+1 On Wed, Feb 16, 2011 at 3:50 PM, MAX STARETS max.star...@oracle.com wrote: +1 On 2/16/2011 9:48 AM, Scott O'Bryan wrote: Hey Everyone, Okay, I have checked in code to address TRINIDAD-2037 which was the issue raised by Matthias in the previous vote[1]. The artifacts have been regenerated and Matthias has tested the fix and it works. This is still a beta release so there are still a few open bugs, but all of the unit tests pass and this beta has undergone some considerable testing since the last release. Therefore I would like to ask for a re-vote on this release. All of the following should be ready for review: * The generated repository and assembly artifacts[2] * The generated source archive[3] * The updated svn repository[4] Please review the artifacts and vote according to the following: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg51466.html [2] https://repository.apache.org/content/repositories/orgapachemyfaces-015/ [3] https://repository.apache.org/content/repositories/orgapachemyfaces-015/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-2/trinidad-2.0.0-beta-2-source-release.zip [4] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.0-beta-2 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Release of Trinidad 2.0.0 Beta 2 (Try 2)
+1 On Wed, Feb 16, 2011 at 8:20 AM, Matthias Wessendorf mat...@apache.orgwrote: +1 On Wed, Feb 16, 2011 at 3:50 PM, MAX STARETS max.star...@oracle.com wrote: +1 On 2/16/2011 9:48 AM, Scott O'Bryan wrote: Hey Everyone, Okay, I have checked in code to address TRINIDAD-2037 which was the issue raised by Matthias in the previous vote[1]. The artifacts have been regenerated and Matthias has tested the fix and it works. This is still a beta release so there are still a few open bugs, but all of the unit tests pass and this beta has undergone some considerable testing since the last release. Therefore I would like to ask for a re-vote on this release. All of the following should be ready for review: * The generated repository and assembly artifacts[2] * The generated source archive[3] * The updated svn repository[4] Please review the artifacts and vote according to the following: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg51466.html [2] https://repository.apache.org/content/repositories/orgapachemyfaces-015/ [3] https://repository.apache.org/content/repositories/orgapachemyfaces-015/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-2/trinidad-2.0.0-beta-2-source-release.zip [4] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.0-beta-2 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Release of Trinidad 2.0.0 Beta 2 (Try 2)
+1
[jira] Resolved: (EXTCDI-122) revisit jndi names
[ https://issues.apache.org/jira/browse/EXTCDI-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTCDI-122. - Resolution: Fixed Fix Version/s: 0.9.3 since the new approach is pluggable we can keep the existing naming convention revisit jndi names -- Key: EXTCDI-122 URL: https://issues.apache.org/jira/browse/EXTCDI-122 Project: MyFaces CODI Issue Type: Task Components: Core Reporter: Gerhard Petracek Fix For: 0.9.3 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release of Trinidad 2.0.0 Beta 2 (Try 2)
+1 -- Blake On 2/16/11 7:20 AM, Matthias Wessendorf wrote: +1 On Wed, Feb 16, 2011 at 3:50 PM, MAX STARETSmax.star...@oracle.com wrote: +1 On 2/16/2011 9:48 AM, Scott O'Bryan wrote: Hey Everyone, Okay, I have checked in code to address TRINIDAD-2037 which was the issue raised by Matthias in the previous vote[1]. The artifacts have been regenerated and Matthias has tested the fix and it works. This is still a beta release so there are still a few open bugs, but all of the unit tests pass and this beta has undergone some considerable testing since the last release. Therefore I would like to ask for a re-vote on this release. All of the following should be ready for review: * The generated repository and assembly artifacts[2] * The generated source archive[3] * The updated svn repository[4] Please review the artifacts and vote according to the following: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg51466.html [2] https://repository.apache.org/content/repositories/orgapachemyfaces-015/ [3] https://repository.apache.org/content/repositories/orgapachemyfaces-015/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-2/trinidad-2.0.0-beta-2-source-release.zip [4] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.0-beta-2
[jira] Created: (TRINIDAD-2038) Need new exception wrapper to know whether JSF needs to report the exception
Need new exception wrapper to know whether JSF needs to report the exception Key: TRINIDAD-2038 URL: https://issues.apache.org/jira/browse/TRINIDAD-2038 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-beta-1 Reporter: hongbing wang There are cases that exception is thrown in update model phase, like model layer validation failure, by model outside of JSF and the exception is also handled and reported outside of JSF. To avoid the component's local value getting reset to null, JSF needs to be notified. The proposed solution is to re-throw a wrappered exception to JSF and also let JSF to know whether it needs to report the exception. Here is the interface of the wrapper: package org.apache.myfaces.trinidad.context; /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during JSF lifycycle and aleady reported, then it should let * JSF know not to report it again. * */ public interface ExceptionWrapper { /** * Return false if JSF doesn't need to report this exception, otherwise ture. */ public boolean isReportingMessage(); } -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2038) Need new exception to know whether JSF needs to report the exception
[ https://issues.apache.org/jira/browse/TRINIDAD-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12995502#comment-12995502 ] Pavitra Subramaniam commented on TRINIDAD-2038: --- Hello Hongbing, You mentioned that exceptions get thrown by model layer outside of JSF. Can you give an e.g., of when this might occur? How exactly will the above interface get used? Thanks Pavitra Need new exception to know whether JSF needs to report the exception Key: TRINIDAD-2038 URL: https://issues.apache.org/jira/browse/TRINIDAD-2038 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-beta-1 Reporter: hongbing wang There are cases that exception is thrown in update model phase, like model layer validation failure, by model outside of JSF and the exception is also handled and reported outside of JSF. To avoid the component's local value getting reset to null, JSF needs to be notified when the it happens. The proposed solution is to re-throw a special exception to JSF and also let JSF to know whether it needs to report the exception. Here is the interface of the exception: package org.apache.myfaces.trinidad.context; /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during JSF lifycycle and aleady reported, then it should let * JSF know not to report it again. * */ public interface Reportable { /** * Return false if JSF doesn't need to report this exception, otherwise true. */ public boolean isReportingMessage(); } -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[Trinidad][API] New Exception tells whether JSF needs to report the exception for TRINIDAD-2038
Hi: This is for JIRA TRINIDAD-2038, please let me know your suggestion. There are cases that exception is thrown in update model phase, like model layer validation failure, by model outside of JSF and the exception is also handled and reported outside of JSF. To avoid the component's local value getting reset to null, JSF needs to be notified when it happens. The proposed solution is to re-throw a special exception to JSF to notify it and also let JSF know whether it needs to report the exception. Here is the interface of the exception: package org.apache.myfaces.trinidad.context; /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during JSF lifycycle and aleady reported, then it should let * JSF know not to report it again. * */ public interface Reportable { /** * Return false if JSF doesn't need to report this exception, otherwise true. */ public boolean isReportingMessage(); } Thanks, Hongbing
Re: [Trinidad][API] New Exception tells whether JSF needs to report the exception for TRINIDAD-2038
Hello Hongbing, You mentioned that exceptions get thrown by model layer outside of JSF. Can you give an e.g., of when this might occur? How exactly will the interface get used? Thanks Pavitra On 2/16/2011 1:01 PM, Hongbing wrote: Hi: This is for JIRA TRINIDAD-2038, please let me know your suggestion. There are cases that exception is thrown in update model phase, like model layer validation failure, by model outside of JSF and the exception is also handled and reported outside of JSF. To avoid the component's local value getting reset to null, JSF needs to be notified when it happens. The proposed solution is to re-throw a special exception to JSF to notify it and also let JSF know whether it needs to report the exception. Here is the interface of the exception: package org.apache.myfaces.trinidad.context; /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during JSF lifycycle and aleady reported, then it should let * JSF know not to report it again. * */ public interface Reportable { /** * Return false if JSF doesn't need to report this exception, otherwise true. */ public boolean isReportingMessage(); } Thanks, Hongbing
[VOTE] Release Tobago 1.0.34
Hello, I would like to release Tobago 1.0.34. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12316162 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-019 The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd
[VOTE] Release Tobago 1.5.0-alpha-2
Hello, I would like to release Tobago 1.5.0-alpha-2. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12314340 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-018 The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd
Re: [Trinidad][API] New Exception tells whether JSF needs to report the exception for TRINIDAD-2038
Hi Pavitra: It can happen in update model phase. For example, Model layer throws exception when attribute value validation fails, binding layer detects it and re-throwd new exception with the new interface to JSF. JSF then can handle it accordingly. thanks, Hongbing On 2/16/2011 2:09 PM, Pavitra Subramaniam wrote: Hello Hongbing, You mentioned that exceptions get thrown by model layer outside of JSF. Can you give an e.g., of when this might occur? How exactly will the interface get used? Thanks Pavitra On 2/16/2011 1:01 PM, Hongbing wrote: Hi: This is for JIRA TRINIDAD-2038, please let me know your suggestion. There are cases that exception is thrown in update model phase, like model layer validation failure, by model outside of JSF and the exception is also handled and reported outside of JSF. To avoid the component's local value getting reset to null, JSF needs to be notified when it happens. The proposed solution is to re-throw a special exception to JSF to notify it and also let JSF know whether it needs to report the exception. Here is the interface of the exception: package org.apache.myfaces.trinidad.context; /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during JSF lifycycle and aleady reported, then it should let * JSF know not to report it again. * */ public interface Reportable { /** * Return false if JSF doesn't need to report this exception, otherwise true. */ public boolean isReportingMessage(); } Thanks, Hongbing
Re: [Trinidad][API] New Exception tells whether JSF needs to report the exception for TRINIDAD-2038
Hogbing, I'm taking a look at the bug now but just so I understand.. When you refer to JSF, I assume you mean the Trinidad renderkit. Is that correct? Scott On Feb 16, 2011, at 4:23 PM, Hongbing hongbing.w...@oracle.com wrote: Hi Pavitra: It can happen in update model phase. For example, Model layer throws exception when attribute value validation fails, binding layer detects it and re-throwd new exception with the new interface to JSF. JSF then can handle it accordingly. thanks, Hongbing On 2/16/2011 2:09 PM, Pavitra Subramaniam wrote: Hello Hongbing, You mentioned that exceptions get thrown by model layer outside of JSF. Can you give an e.g., of when this might occur? How exactly will the interface get used? Thanks Pavitra On 2/16/2011 1:01 PM, Hongbing wrote: Hi: This is for JIRA TRINIDAD-2038, please let me know your suggestion. There are cases that exception is thrown in update model phase, like model layer validation failure, by model outside of JSF and the exception is also handled and reported outside of JSF. To avoid the component's local value getting reset to null, JSF needs to be notified when it happens. The proposed solution is to re-throw a special exception to JSF to notify it and also let JSF know whether it needs to report the exception. Here is the interface of the exception: package org.apache.myfaces.trinidad.context; /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during JSF lifycycle and aleady reported, then it should let * JSF know not to report it again. * */ public interface Reportable { /** * Return false if JSF doesn't need to report this exception, otherwise true. */ public boolean isReportingMessage(); } Thanks, Hongbing
[jira] Commented: (TRINIDAD-2038) Need new exception to know whether JSF needs to report the exception
[ https://issues.apache.org/jira/browse/TRINIDAD-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12995609#comment-12995609 ] Scott O'Bryan commented on TRINIDAD-2038: - Also, by JSF, I'm assuming that you mean the Trinidad renderkit and NOT JSF itself. In general, I think I would prefer to have a new exception rather then making exception logic more complex.. What exactly does the interface gain us here? Need new exception to know whether JSF needs to report the exception Key: TRINIDAD-2038 URL: https://issues.apache.org/jira/browse/TRINIDAD-2038 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-beta-1 Reporter: hongbing wang There are cases that exception is thrown in update model phase, like model layer validation failure, by model outside of JSF and the exception is also handled and reported outside of JSF. To avoid the component's local value getting reset to null, JSF needs to be notified when it happens. The proposed solution is to re-throw a special exception to JSF notify it and also let JSF know whether it needs to report the exception. Here is the interface of the exception: package org.apache.myfaces.trinidad.context; /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during JSF lifycycle and already reported, then it should let * JSF know not to report it again. * */ public interface Reportable { /** * Return false if JSF doesn't need to report this exception, otherwise true. */ public boolean isReportingMessage(); } -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Trinidad][API] New Exception tells whether JSF needs to report the exception for TRINIDAD-2038
Hi Scott: One example is in the following UIXEditableValue.updateModel(FacesContext context) code, public void updateModel(FacesContext context) { try { Object localValue = getLocalValue(); expression.setValue(context.getELContext(), localValue); setValue(null); setLocalValueSet(false); if (_LOG.isFiner()) { _LOG.finer(Wrote value {0} to model {1} in component {2}, new Object[]{localValue, expression.getExpressionString(), this}); } } catch (RuntimeException e) { ... expression.setValue(context.getELContext(), localValue) calls binding code and then the model's code, where exception can be thrown. In the catch part, we want to skip reporting the exception if it is handled by model/controller code. Thanks, Hongbing On 2/16/2011 4:23 PM, Scott O'Bryan wrote: Hogbing, I'm taking a look at the bug now but just so I understand.. When you refer to JSF, I assume you mean the Trinidad renderkit. Is that correct? Scott On Feb 16, 2011, at 4:23 PM, Hongbinghongbing.w...@oracle.com wrote: Hi Pavitra: It can happen in update model phase. For example, Model layer throws exception when attribute value validation fails, binding layer detects it and re-throwd new exception with the new interface to JSF. JSF then can handle it accordingly. thanks, Hongbing On 2/16/2011 2:09 PM, Pavitra Subramaniam wrote: Hello Hongbing, You mentioned that exceptions get thrown by model layer outside of JSF. Can you give an e.g., of when this might occur? How exactly will the interface get used? Thanks Pavitra On 2/16/2011 1:01 PM, Hongbing wrote: Hi: This is for JIRA TRINIDAD-2038, please let me know your suggestion. There are cases that exception is thrown in update model phase, like model layer validation failure, by model outside of JSF and the exception is also handled and reported outside of JSF. To avoid the component's local value getting reset to null, JSF needs to be notified when it happens. The proposed solution is to re-throw a special exception to JSF to notify it and also let JSF know whether it needs to report the exception. Here is the interface of the exception: package org.apache.myfaces.trinidad.context; /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during JSF lifycycle and aleady reported, then it should let * JSF know not to report it again. * */ public interface Reportable { /** * Return false if JSF doesn't need to report this exception, otherwise true. */ public boolean isReportingMessage(); } Thanks, Hongbing
Re: [Trinidad][API] New Exception tells whether JSF needs to report the exception for TRINIDAD-2038
If this exception is handled, why is it rethrown? What would you expect Trinidad to do in this case? On Feb 16, 2011, at 5:37 PM, Hongbing hongbing.w...@oracle.com wrote: Hi Scott: One example is in the following UIXEditableValue.updateModel(FacesContext context) code, public void updateModel(FacesContext context) { try { Object localValue = getLocalValue(); expression.setValue(context.getELContext(), localValue); setValue(null); setLocalValueSet(false); if (_LOG.isFiner()) { _LOG.finer(Wrote value {0} to model {1} in component {2}, new Object[]{localValue, expression.getExpressionString(), this}); } } catch (RuntimeException e) { ... expression.setValue(context.getELContext(), localValue) calls binding code and then the model's code, where exception can be thrown. In the catch part, we want to skip reporting the exception if it is handled by model/controller code. Thanks, Hongbing On 2/16/2011 4:23 PM, Scott O'Bryan wrote: Hogbing, I'm taking a look at the bug now but just so I understand.. When you refer to JSF, I assume you mean the Trinidad renderkit. Is that correct? Scott On Feb 16, 2011, at 4:23 PM, Hongbinghongbing.w...@oracle.com wrote: Hi Pavitra: It can happen in update model phase. For example, Model layer throws exception when attribute value validation fails, binding layer detects it and re-throwd new exception with the new interface to JSF. JSF then can handle it accordingly. thanks, Hongbing On 2/16/2011 2:09 PM, Pavitra Subramaniam wrote: Hello Hongbing, You mentioned that exceptions get thrown by model layer outside of JSF. Can you give an e.g., of when this might occur? How exactly will the interface get used? Thanks Pavitra On 2/16/2011 1:01 PM, Hongbing wrote: Hi: This is for JIRA TRINIDAD-2038, please let me know your suggestion. There are cases that exception is thrown in update model phase, like model layer validation failure, by model outside of JSF and the exception is also handled and reported outside of JSF. To avoid the component's local value getting reset to null, JSF needs to be notified when it happens. The proposed solution is to re-throw a special exception to JSF to notify it and also let JSF know whether it needs to report the exception. Here is the interface of the exception: package org.apache.myfaces.trinidad.context; /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during JSF lifycycle and aleady reported, then it should let * JSF know not to report it again. * */ public interface Reportable { /** * Return false if JSF doesn't need to report this exception, otherwise true. */ public boolean isReportingMessage(); } Thanks, Hongbing
Re: [Trinidad][API] New Exception tells whether JSF needs to report the exception for TRINIDAD-2038
In an ideal world, validation occurs in PROCESS_VALIDATIONS phase of JSF lifecycle, so there shouldn't be any problems pushing the validated value to the model. Our Trinidad renderkit implements the lifecycle in such a way that after PROCESS_VALIDATIONS phase, the submitted value is cleared, and after UPDATE_MODEL phase, the local value is cleared. But in reality, depending on the implementation of the model, validation exception can occur in different phases other than PROCESS_VALIDATIONS phase. Thus Trinidad renderkit was enhanced to catch exception in UPDATE_MODEL phase and not clear the local value in case an exception is caught. But what to do with this exception? Still, the model implementation could choose to have its own error handling logic to report this exception, and this exception could be a chain of errors that model wants to report all of them. In such case, we would like to have the ability to notify Trinidad renderkit that an exception occurs, don't clear the local value, but don't report it either since model will report it. Thanks, Jing Scott O'Bryan wrote: Hogbing, I'm taking a look at the bug now but just so I understand.. When you refer to JSF, I assume you mean the Trinidad renderkit. Is that correct? Scott On Feb 16, 2011, at 4:23 PM, Hongbing hongbing.w...@oracle.com wrote: Hi Pavitra: It can happen in update model phase. For example, Model layer throws exception when attribute value validation fails, binding layer detects it and re-throwd new exception with the new interface to JSF. JSF then can handle it accordingly. thanks, Hongbing On 2/16/2011 2:09 PM, Pavitra Subramaniam wrote: Hello Hongbing, You mentioned that exceptions get thrown by model layer outside of JSF. Can you give an e.g., of when this might occur? How exactly will the interface get used? Thanks Pavitra On 2/16/2011 1:01 PM, Hongbing wrote: Hi: This is for JIRA TRINIDAD-2038, please let me know your suggestion. There are cases that exception is thrown in update model phase, like model layer validation failure, by model outside of JSF and the exception is also handled and reported outside of JSF. To avoid the component's local value getting reset to null, JSF needs to be notified when it happens. The proposed solution is to re-throw a special exception to JSF to notify it and also let JSF know whether it needs to report the exception. Here is the interface of the exception: package org.apache.myfaces.trinidad.context; /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during JSF lifycycle and aleady reported, then it should let * JSF know not to report it again. * */ public interface Reportable { /** * Return false if JSF doesn't need to report this exception, otherwise true. */ public boolean isReportingMessage(); } Thanks, Hongbing
Re: [Trinidad][API] New Exception tells whether JSF needs to report the exception for TRINIDAD-2038
The issue isn't that the problem has been handled by the model. It hasn't. Therefore the model has to throw a RuntimeException in this case so that the component knows to preserve its local value. That's all good. The problem occurs if the model has its own mechanisms for reporting problems. In that case, we want to avoid reporting the same problem twice and that is where the interface comes in. The model wants to tell the view that there was a problem, but that the model will take care of reporting it, so the view needn't bother. -- Blake Sullivan On 2/16/11 4:39 PM, Scott O'Bryan wrote: If this exception is handled, why is it rethrown? What would you expect Trinidad to do in this case? On Feb 16, 2011, at 5:37 PM, Hongbinghongbing.w...@oracle.com wrote: Hi Scott: One example is in the following UIXEditableValue.updateModel(FacesContext context) code, public void updateModel(FacesContext context) { try { Object localValue = getLocalValue(); expression.setValue(context.getELContext(), localValue); setValue(null); setLocalValueSet(false); if (_LOG.isFiner()) { _LOG.finer(Wrote value {0} to model {1} in component {2}, new Object[]{localValue, expression.getExpressionString(), this}); } } catch (RuntimeException e) { ... expression.setValue(context.getELContext(), localValue) calls binding code and then the model's code, where exception can be thrown. In the catch part, we want to skip reporting the exception if it is handled by model/controller code. Thanks, Hongbing On 2/16/2011 4:23 PM, Scott O'Bryan wrote: Hogbing, I'm taking a look at the bug now but just so I understand.. When you refer to JSF, I assume you mean the Trinidad renderkit. Is that correct? Scott On Feb 16, 2011, at 4:23 PM, Hongbinghongbing.w...@oracle.com wrote: Hi Pavitra: It can happen in update model phase. For example, Model layer throws exception when attribute value validation fails, binding layer detects it and re-throwd new exception with the new interface to JSF. JSF then can handle it accordingly. thanks, Hongbing On 2/16/2011 2:09 PM, Pavitra Subramaniam wrote: Hello Hongbing, You mentioned that exceptions get thrown by model layer outside of JSF. Can you give an e.g., of when this might occur? How exactly will the interface get used? Thanks Pavitra On 2/16/2011 1:01 PM, Hongbing wrote: Hi: This is for JIRA TRINIDAD-2038, please let me know your suggestion. There are cases that exception is thrown in update model phase, like model layer validation failure, by model outside of JSF and the exception is also handled and reported outside of JSF. To avoid the component's local value getting reset to null, JSF needs to be notified when it happens. The proposed solution is to re-throw a special exception to JSF to notify it and also let JSF know whether it needs to report the exception. Here is the interface of the exception: package org.apache.myfaces.trinidad.context; /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during JSF lifycycle and aleady reported, then it should let * JSF know not to report it again. * */ public interface Reportable { /** * Return false if JSF doesn't need to report this exception, otherwise true. */ public boolean isReportingMessage(); } Thanks, Hongbing
Re: [Trinidad][API] New Exception tells whether JSF needs to report the exception for TRINIDAD-2038
Ahh cool. Thanks Blake. That clears things up consoderably. I guess I'm cool with it but I'm wondering if this might not be better served by a RUNTIME annotation or even a new Trinidad exception class. Having an interface on an exception seems a bit silly to me because it requires some implementation. Especially if that interface only returns a Boolean. An annotation marker might be a better thing to use if you need to return exceptions with multiple origins or if these wrapper exceptions can all come from the same base exception, a special Trinidad exception type would be much more efficient because we could simply return an instanceof and/or provide overloadable logic to determine if logging is needed. Just my .02, but I'm good with it.. ;) Scott On Feb 16, 2011, at 5:46 PM, Blake Sullivan blake.sulli...@oracle.com wrote: The issue isn't that the problem has been handled by the model. It hasn't. Therefore the model has to throw a RuntimeException in this case so that the component knows to preserve its local value. That's all good. The problem occurs if the model has its own mechanisms for reporting problems. In that case, we want to avoid reporting the same problem twice and that is where the interface comes in. The model wants to tell the view that there was a problem, but that the model will take care of reporting it, so the view needn't bother. -- Blake Sullivan On 2/16/11 4:39 PM, Scott O'Bryan wrote: If this exception is handled, why is it rethrown? What would you expect Trinidad to do in this case? On Feb 16, 2011, at 5:37 PM, Hongbinghongbing.w...@oracle.com wrote: Hi Scott: One example is in the following UIXEditableValue.updateModel(FacesContext context) code, public void updateModel(FacesContext context) { try { Object localValue = getLocalValue(); expression.setValue(context.getELContext(), localValue); setValue(null); setLocalValueSet(false); if (_LOG.isFiner()) { _LOG.finer(Wrote value {0} to model {1} in component {2}, new Object[]{localValue, expression.getExpressionString(), this}); } } catch (RuntimeException e) { ... expression.setValue(context.getELContext(), localValue) calls binding code and then the model's code, where exception can be thrown. In the catch part, we want to skip reporting the exception if it is handled by model/controller code. Thanks, Hongbing On 2/16/2011 4:23 PM, Scott O'Bryan wrote: Hogbing, I'm taking a look at the bug now but just so I understand.. When you refer to JSF, I assume you mean the Trinidad renderkit. Is that correct? Scott On Feb 16, 2011, at 4:23 PM, Hongbinghongbing.w...@oracle.com wrote: Hi Pavitra: It can happen in update model phase. For example, Model layer throws exception when attribute value validation fails, binding layer detects it and re-throwd new exception with the new interface to JSF. JSF then can handle it accordingly. thanks, Hongbing On 2/16/2011 2:09 PM, Pavitra Subramaniam wrote: Hello Hongbing, You mentioned that exceptions get thrown by model layer outside of JSF. Can you give an e.g., of when this might occur? How exactly will the interface get used? Thanks Pavitra On 2/16/2011 1:01 PM, Hongbing wrote: Hi: This is for JIRA TRINIDAD-2038, please let me know your suggestion. There are cases that exception is thrown in update model phase, like model layer validation failure, by model outside of JSF and the exception is also handled and reported outside of JSF. To avoid the component's local value getting reset to null, JSF needs to be notified when it happens. The proposed solution is to re-throw a special exception to JSF to notify it and also let JSF know whether it needs to report the exception. Here is the interface of the exception: package org.apache.myfaces.trinidad.context; /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during JSF lifycycle and aleady reported, then it should let * JSF know not to report it again. * */ public interface Reportable { /** * Return false if JSF doesn't need to report this exception, otherwise true. */ public boolean isReportingMessage(); } Thanks, Hongbing
Re: [Trinidad][API] New Exception tells whether JSF needs to report the exception for TRINIDAD-2038
Sounds good. Thanks. +1 with minor typo corrections in comments. /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during the JSF _lifecycle and already_ reported, then * it should let JSF know not to report it again. * */ On 2/16/2011 4:45 PM, Blake Sullivan wrote: The issue isn't that the problem has been handled by the model. It hasn't. Therefore the model has to throw a RuntimeException in this case so that the component knows to preserve its local value. That's all good. The problem occurs if the model has its own mechanisms for reporting problems. In that case, we want to avoid reporting the same problem twice and that is where the interface comes in. The model wants to tell the view that there was a problem, but that the model will take care of reporting it, so the view needn't bother. -- Blake Sullivan On 2/16/11 4:39 PM, Scott O'Bryan wrote: If this exception is handled, why is it rethrown? What would you expect Trinidad to do in this case? On Feb 16, 2011, at 5:37 PM, Hongbinghongbing.w...@oracle.com wrote: Hi Scott: One example is in the following UIXEditableValue.updateModel(FacesContext context) code, public void updateModel(FacesContext context) { try { Object localValue = getLocalValue(); expression.setValue(context.getELContext(), localValue); setValue(null); setLocalValueSet(false); if (_LOG.isFiner()) { _LOG.finer(Wrote value {0} to model {1} in component {2}, new Object[]{localValue, expression.getExpressionString(), this}); } } catch (RuntimeException e) { ... expression.setValue(context.getELContext(), localValue) calls binding code and then the model's code, where exception can be thrown. In the catch part, we want to skip reporting the exception if it is handled by model/controller code. Thanks, Hongbing On 2/16/2011 4:23 PM, Scott O'Bryan wrote: Hogbing, I'm taking a look at the bug now but just so I understand.. When you refer to JSF, I assume you mean the Trinidad renderkit. Is that correct? Scott On Feb 16, 2011, at 4:23 PM, Hongbinghongbing.w...@oracle.com wrote: Hi Pavitra: It can happen in update model phase. For example, Model layer throws exception when attribute value validation fails, binding layer detects it and re-throwd new exception with the new interface to JSF. JSF then can handle it accordingly. thanks, Hongbing On 2/16/2011 2:09 PM, Pavitra Subramaniam wrote: Hello Hongbing, You mentioned that exceptions get thrown by model layer outside of JSF. Can you give an e.g., of when this might occur? How exactly will the interface get used? Thanks Pavitra On 2/16/2011 1:01 PM, Hongbing wrote: Hi: This is for JIRA TRINIDAD-2038, please let me know your suggestion. There are cases that exception is thrown in update model phase, like model layer validation failure, by model outside of JSF and the exception is also handled and reported outside of JSF. To avoid the component's local value getting reset to null, JSF needs to be notified when it happens. The proposed solution is to re-throw a special exception to JSF to notify it and also let JSF know whether it needs to report the exception. Here is the interface of the exception: package org.apache.myfaces.trinidad.context; /** * Interface for exceptions that tells whether the exception needs to be reported. * If an exception is thrown during JSF lifycycle and aleady reported, then it should let * JSF know not to report it again. * */ public interface Reportable { /** * Return false if JSF doesn't need to report this exception, otherwise true. */ public boolean isReportingMessage(); } Thanks, Hongbing
Re: [VOTE] Release Tobago 1.5.0-alpha-2
+1 - I did a source download and the build went fine -M On Thu, Feb 17, 2011 at 12:00 AM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, I would like to release Tobago 1.5.0-alpha-2. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12314340 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-018 The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf