You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Stefan Ocke (JIRA)" <ji...@apache.org> on 2012/10/02 14:47:07 UTC
[jira] [Created] (WICKET-4799) FeedbackMessage.getReporter does not
survive requests
Stefan Ocke created WICKET-4799:
-----------------------------------
Summary: FeedbackMessage.getReporter does not survive requests
Key: WICKET-4799
URL: https://issues.apache.org/jira/browse/WICKET-4799
Project: Wicket
Issue Type: Bug
Affects Versions: 6.0.0
Reporter: Stefan Ocke
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are, however, some classe, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecates), if it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4799) FeedbackMessage.getReporter does not
survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Ocke updated WICKET-4799:
--------------------------------
Component/s: wicket
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are, however, some classe, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecates), if it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4799) FeedbackMessage.getReporter does
not survive requests
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467686#comment-13467686 ]
Martin Grigorov commented on WICKET-4799:
-----------------------------------------
This looks like a duplicate of WICKET-4773.
Can you try with latest 6.x ?
There is a running vote for 6.1.0 but you will have to build it locally ...
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4799) FeedbackMessage.getReporter does
not survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467723#comment-13467723 ]
Stefan Ocke commented on WICKET-4799:
-------------------------------------
Same issue with 6.2.0-SNAPSHOT.
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4799) FeedbackMessage.getReporter does not
survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Ocke updated WICKET-4799:
--------------------------------
Description:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, the new ComponentFeedbackPanel could use FeedbackCollector.
was:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter.
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, the new ComponentFeedbackPanel could use FeedbackCollector.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4799) FeedbackMessage.getReporter does
not survive requests - ComponentFeedbackMessageFilter and
ContainerFeedbackMessageFilter fail
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Grigorov resolved WICKET-4799.
-------------------------------------
Resolution: Cannot Reproduce
We need a test case to be able to debug it.
If the feedback message is rendered then it should be removed and this is what happens now.
Until the feedback message is not rendered it keeps a reference to its reporter.
> FeedbackMessage.getReporter does not survive requests - ComponentFeedbackMessageFilter and ContainerFeedbackMessageFilter fail
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ContainerFeedbackMessageFilter that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4799) FeedbackMessage.getReporter does
not survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467692#comment-13467692 ]
Stefan Ocke commented on WICKET-4799:
-------------------------------------
Thanks for quick response. Sorry, I did not see WICKET-4773 yet. I will have a look at it.
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4799) FeedbackMessage.getReporter does not
survive requests - ComponentFeedbackMessageFilter and
ContainerFeedbackMessageFilter fail
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Ocke updated WICKET-4799:
--------------------------------
Description:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ContainerFeedbackMessageFilter that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
was:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
> FeedbackMessage.getReporter does not survive requests - ComponentFeedbackMessageFilter and ContainerFeedbackMessageFilter fail
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ContainerFeedbackMessageFilter that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4799) FeedbackMessage.getReporter does
not survive requests - ComponentFeedbackMessageFilter and
ContainerFeedbackMessageFilter fail
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467911#comment-13467911 ]
Stefan Ocke commented on WICKET-4799:
-------------------------------------
I changed the titel and description a bit, since not only ComponentFeedbackMessageFilter suffers from this issue, but also ContainerFeedbackMessageFilter. Both rely on FeedbackMessage.getReporter.
> FeedbackMessage.getReporter does not survive requests - ComponentFeedbackMessageFilter and ContainerFeedbackMessageFilter fail
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ContainerFeedbackMessageFilter that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (WICKET-4799) FeedbackMessage.getReporter
does not survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467716#comment-13467716 ]
Stefan Ocke edited comment on WICKET-4799 at 10/3/12 12:35 AM:
---------------------------------------------------------------
Mmh, I just looked at the diff in GIT: https://github.com/apache/wicket/commit/bf8a9576c3414a1f497ac71f1a56be1f0f31a7ea
I think, this is not sufficient to fix the issue (at least not the one I have). It does not clean the reporter anymore if the message has been rendered.
However, In my case the message already has been rendered during the intial request. And now it shall be rendered again during an ajax request (but the field shall not be validated again. I need to use the "old" message... ). But the reporter is still null...
So please consider my proposals above for solution.
(To give you some more details:
I have a dynamic list of form components, where the user can add new fields. Adding new fields is the AJAX-Request. This request currently removes the validation messages of already validates fields, since I have to AJAX-refresh the whole list of fields when adding a new one. On the other hand, I cannot re-create the messages by validating again, since adding new fields shall not trigger (new) validation.
)
was (Author: stefanoc):
Mmh, I just looked at the diff in GIT: https://github.com/apache/wicket/commit/bf8a9576c3414a1f497ac71f1a56be1f0f31a7ea
I think, this is not sufficient to fix the issue (at least the one I have). It does not clean the reporter anymore if the message has been rendered.
However, In my case the message already has been rendered during the intial request. And now it shall be rendered again during an ajax request (but the field shall not be validated again. I need to use the "old" message... ). But the reporter is still null...
So please consider my proposals above for solution.
(To give you some more details:
I have a dynamic list of form components, where the user can add new fields. Adding new fields is the AJAX-Request. This request currently removes the validation messages of already validates fields, since I have to AJAX-refresh the whole list of fields when adding a new one. On the other hand, I cannot re-create the messages by validating again, since adding new fields shall not trigger (new) validation.
)
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4799) FeedbackMessage.getReporter does not
survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Ocke updated WICKET-4799:
--------------------------------
Labels: FeedbackMessage.getReporter (was: )
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are, however, some classe, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecates), if it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4799) FeedbackMessage.getReporter does
not survive requests - ComponentFeedbackMessageFilter and
ContainerFeedbackMessageFilter fail
Posted by "Emond Papegaaij (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13472589#comment-13472589 ]
Emond Papegaaij commented on WICKET-4799:
-----------------------------------------
I thought so, but wasn't sure. In that case, there is no need to clear reporter at all.
> FeedbackMessage.getReporter does not survive requests - ComponentFeedbackMessageFilter and ContainerFeedbackMessageFilter fail
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ContainerFeedbackMessageFilter that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (WICKET-4799) FeedbackMessage.getReporter
does not survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467716#comment-13467716 ]
Stefan Ocke edited comment on WICKET-4799 at 10/3/12 12:44 AM:
---------------------------------------------------------------
Mmh, I just looked at the diff in GIT: https://github.com/apache/wicket/commit/bf8a9576c3414a1f497ac71f1a56be1f0f31a7ea
I think, this is not sufficient to fix the issue (at least not the one I have). It does not clean the reporter anymore if the message has been rendered.
However, In my case the message already has been rendered during the intial request. And now it shall be rendered again during an ajax request (but the field shall not be validated again. I need to use the "old" message... ). But the reporter is still null...
So please consider my proposals above for solution.
(To give you some more details:
I have a dynamic list of form components, where the user can add new fields. Adding new fields is the AJAX-Request. This request currently removes the validation messages of already validated fields, since I have to AJAX-refresh the whole list of fields when adding a new one. On the other hand, I cannot re-create the messages by validating again, since adding new fields shall not trigger (new) validation.
)
was (Author: stefanoc):
Mmh, I just looked at the diff in GIT: https://github.com/apache/wicket/commit/bf8a9576c3414a1f497ac71f1a56be1f0f31a7ea
I think, this is not sufficient to fix the issue (at least not the one I have). It does not clean the reporter anymore if the message has been rendered.
However, In my case the message already has been rendered during the intial request. And now it shall be rendered again during an ajax request (but the field shall not be validated again. I need to use the "old" message... ). But the reporter is still null...
So please consider my proposals above for solution.
(To give you some more details:
I have a dynamic list of form components, where the user can add new fields. Adding new fields is the AJAX-Request. This request currently removes the validation messages of already validated fields, since I have to AJAX-refresh the whole list of fields when adding a new one. On the other hand, I cannot re-create the messages by validating again, since adding new fields shall not trigger (new) validation.
)
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4799) FeedbackMessage.getReporter does
not survive requests - ComponentFeedbackMessageFilter and
ContainerFeedbackMessageFilter fail
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489441#comment-13489441 ]
Martin Grigorov commented on WICKET-4799:
-----------------------------------------
Fixed with https://issues.apache.org/jira/browse/WICKET-4848
> FeedbackMessage.getReporter does not survive requests - ComponentFeedbackMessageFilter and ContainerFeedbackMessageFilter fail
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ContainerFeedbackMessageFilter that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4799) FeedbackMessage.getReporter does
not survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467709#comment-13467709 ]
Stefan Ocke commented on WICKET-4799:
-------------------------------------
I tried with 6.1-SNAPSHOT from snapshot repo. But the issue ist still there. WICKET-4773 has been fixed on 22/Sep . So I assumed it's in the snapshot ()...
Will wait for 6.1 release now and try again.
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4799) FeedbackMessage.getReporter does not
survive requests - ComponentFeedbackMessageFilter and
ContainerFeedbackMessageFilter fail
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Ocke updated WICKET-4799:
--------------------------------
Summary: FeedbackMessage.getReporter does not survive requests - ComponentFeedbackMessageFilter and ContainerFeedbackMessageFilter fail (was: FeedbackMessage.getReporter does not survive requests)
> FeedbackMessage.getReporter does not survive requests - ComponentFeedbackMessageFilter and ContainerFeedbackMessageFilter fail
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4799) FeedbackMessage.getReporter does not
survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Ocke updated WICKET-4799:
--------------------------------
Description:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter.
was:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter.
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (WICKET-4799) FeedbackMessage.getReporter
does not survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467716#comment-13467716 ]
Stefan Ocke edited comment on WICKET-4799 at 10/3/12 12:36 AM:
---------------------------------------------------------------
Mmh, I just looked at the diff in GIT: https://github.com/apache/wicket/commit/bf8a9576c3414a1f497ac71f1a56be1f0f31a7ea
I think, this is not sufficient to fix the issue (at least not the one I have). It does not clean the reporter anymore if the message has been rendered.
However, In my case the message already has been rendered during the intial request. And now it shall be rendered again during an ajax request (but the field shall not be validated again. I need to use the "old" message... ). But the reporter is still null...
So please consider my proposals above for solution.
(To give you some more details:
I have a dynamic list of form components, where the user can add new fields. Adding new fields is the AJAX-Request. This request currently removes the validation messages of already validated fields, since I have to AJAX-refresh the whole list of fields when adding a new one. On the other hand, I cannot re-create the messages by validating again, since adding new fields shall not trigger (new) validation.
)
was (Author: stefanoc):
Mmh, I just looked at the diff in GIT: https://github.com/apache/wicket/commit/bf8a9576c3414a1f497ac71f1a56be1f0f31a7ea
I think, this is not sufficient to fix the issue (at least not the one I have). It does not clean the reporter anymore if the message has been rendered.
However, In my case the message already has been rendered during the intial request. And now it shall be rendered again during an ajax request (but the field shall not be validated again. I need to use the "old" message... ). But the reporter is still null...
So please consider my proposals above for solution.
(To give you some more details:
I have a dynamic list of form components, where the user can add new fields. Adding new fields is the AJAX-Request. This request currently removes the validation messages of already validates fields, since I have to AJAX-refresh the whole list of fields when adding a new one. On the other hand, I cannot re-create the messages by validating again, since adding new fields shall not trigger (new) validation.
)
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4799) FeedbackMessage.getReporter does not
survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Ocke updated WICKET-4799:
--------------------------------
Description:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecates), if it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter.
was:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are, however, some classe, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecates), if it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter.
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecates), if it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4799) FeedbackMessage.getReporter does
not survive requests
Posted by "Emond Papegaaij (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467727#comment-13467727 ]
Emond Papegaaij commented on WICKET-4799:
-----------------------------------------
I did not dare to not clear reporter at all, because feedback messages can still be stored in the session. I don't know if a feedback in the session can also have a reporter, if so, not clearing it might result in page-leaks. If reporter is always null for feedback messages in the session, we can remove the clear entirely.
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4799) FeedbackMessage.getReporter does
not survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467716#comment-13467716 ]
Stefan Ocke commented on WICKET-4799:
-------------------------------------
Mmh, I just looked at the diff in GIT: https://github.com/apache/wicket/commit/bf8a9576c3414a1f497ac71f1a56be1f0f31a7ea
I think, this is not sufficient to fix the issue (at least the one I have). It does not clean the reporter anymore if the message has been rendered.
However, In my case the message already has been rendered during the intial request. And now it shall be rendered again during an ajax request (but the field shall not be validated again. I need to use the "old" message... ). But the reporter is still null...
So please consider my proposals above for solution.
(To give you some more details:
I have a dynamic list of form components, where the user can add new fields. Adding new fields is the AJAX-Request. This request currently removes the validation messages of already validates fields, since I have to AJAX-refresh the whole list of fields when adding a new one. On the other hand, I cannot re-create the messages by validating again, since adding new fields shall not trigger (new) validation.
)
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4799) FeedbackMessage.getReporter does not
survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Ocke updated WICKET-4799:
--------------------------------
Description:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
was:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, the new ComponentFeedbackPanel could use FeedbackCollector.
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4799) FeedbackMessage.getReporter does
not survive requests
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467715#comment-13467715 ]
Martin Grigorov commented on WICKET-4799:
-----------------------------------------
Better try with 6.2.0-SNAPSHOT. This is latest version.
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ComponentFeedbackPanel that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4799) FeedbackMessage.getReporter does not
survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Ocke updated WICKET-4799:
--------------------------------
Description:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter.
was:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecates), if it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter.
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4799) FeedbackMessage.getReporter does
not survive requests - ComponentFeedbackMessageFilter and
ContainerFeedbackMessageFilter fail
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13472442#comment-13472442 ]
Martin Grigorov commented on WICKET-4799:
-----------------------------------------
[~stefanoc]: could you please attach a failing quickstart ?
[~papegaaij]: if feedback is stored in the session then it has no Component reporter.
> FeedbackMessage.getReporter does not survive requests - ComponentFeedbackMessageFilter and ContainerFeedbackMessageFilter fail
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecated), as it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter / ContainerFeedbackMessageFilter that do not rely on FeedbackMessage.getReporter. For example, ComponentFeedbackPanel / FeedbackPanle could pass through the considered component to the FeedbackCollector that is created in FeedbackMessagesModel.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4799) FeedbackMessage.getReporter does not
survive requests
Posted by "Stefan Ocke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Ocke updated WICKET-4799:
--------------------------------
Description:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecates), if it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter.
was:
Might sound like a duplicate to WICKET-4544, but please reconsider the following:
- Wicket Migration guide, says:
"Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
Proposals:
a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
or:
b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages
or:
c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecates), if it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter.
> FeedbackMessage.getReporter does not survive requests
> -----------------------------------------------------
>
> Key: WICKET-4799
> URL: https://issues.apache.org/jira/browse/WICKET-4799
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0
> Reporter: Stefan Ocke
> Labels: FeedbackMessage.getReporter
>
> Might sound like a duplicate to WICKET-4544, but please reconsider the following:
> - Wicket Migration guide, says:
> "Feedback messages reported against components are now stored in component's metadata rather then in session. This will allow them to survive across requests, see WICKET-2705. When session and components are detached they will run this filter on any stored messages, all messages accepted by the filter are removed."
> As far as I understand the main intention of this was to let FeedbackMessages survive AJAX-Request.
> But: due to WICKET-2384 , on the messages, that are not removed, still the reporter is set to null.
> There are - however - some classes, that depend on the reporter set properly. Especially, this is true for ComponentFeedbackMessageFilter. It uses the reportert to determine, if a feedback message belongst to a certain (form) component.
> So, if we have a form with FeedbackPanels on each form component, and they use ComponentFeedbackMessageFilter, we still have the effect, that the feedback messages disappear on Ajax Requests. IMHO, this is against the intention of WICKET-2705.
> Proposals:
> a) Please reconsider the solution for WICKET-2384. Does the reporter always have to be nullified?
> or:
> b) Please make FormComponent to somehow restore the reporter for its own FeedbackMessages when the form component is de-serailized.
> or:
> c) Remove FeedbackMessage.getReporter completely (or at least, make it deprecates), if it cannot be used consistently. Provide alternatives to ComponentFeedbackMessageFilter.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira