[
https://issues.apache.org/jira/browse/WICKET-6600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16660336#comment-16660336
]
Gert-Jan Schouten commented on WICKET-6600:
-------------------------------------------
Hello Sven,
No, my suggestion is purely for the production config. The Exception in dev
config is fine with me. I see your point regarding the stacktrace. Perhaps it's
possible to then simply change the log level to WARN? After all, it's a similar
error to "Component not rendered because it was already removed from page" and
that one is logged at WARN without stacktrace as well.
The thing is, we have email notifications set up for ERROR logs, as I can
imagine a lot of deployments have, so logging this on WARN will improve things
for us. And it really is a warning, not an error, because nothing actually goes
wrong.
Yes, the one example that I mentioned can indeed be fixed by adding things to
the target first, but as I said, there are cases where that is not an option. I
don't think Wicket should limit the things you can do with an
AjaxRequestTarget: people are used to adding stuff to it and in a complex
application where multiple components use each other's execution hook methods
and take care of their own little area without having or wanting to worry about
what else is going on on the Page when a user clicks a button, it would be
better in my opinion if Wicket would be more lenient and just warns about
Components being added that are no longer on the Page without throwing an ERROR
level log message.
> Error logging in AjaxRequestHandler is too strict
> -------------------------------------------------
>
> Key: WICKET-6600
> URL: https://issues.apache.org/jira/browse/WICKET-6600
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
> Affects Versions: 8.0.0
> Reporter: Gert-Jan Schouten
> Priority: Major
>
> As a result of these three commits:
> *
> [https://github.com/apache/wicket/commit/dec1293da853357f483eadec4616c9758ea025f9#diff-8964e43671328bf6f9b1d75703103db8]
> *
> [https://github.com/apache/wicket/commit/3be55cf5a24982cfca400225aabb6c4296859a7d#diff-8964e43671328bf6f9b1d75703103db8]
> *
> [https://github.com/apache/wicket/commit/830fb15c333ad6099f466b2344a84b513690db86#diff-8964e43671328bf6f9b1d75703103db8]
> Wicket now logs a stacktrace on error level if you add something to the
> AjaxRequestTarget that has been removed from the page. I don't think this is
> a good idea, because you're not always in control of what happens in an Ajax
> call. Imagine, for example, the following scenario:
> {code:java}
> public abstract class MyPanel extends Panel {
> public MyPanel(String id) {
> super(id);
> this.setOutputMarkupId(true);
> this.add(new AjaxLink("myLink") {
> public void onClick(final AjaxRequestTarget target) {
> this.executeImportantWork(target);
> //Display something nice on this Panel
> //...
> target.add(MyPanel.this); //In order to show the nice things
> }
> });
> }
> protected abstract void executeImportantWork(AjaxRequestTarget target);
> }
> {code}
> Now, what if the user of MyPanel actually adds an instance of MyPanel to the
> Page and then, in executeImportantWork, removes it and replaces it with smth
> else? Then, you get an error in the log, everytime someone clicks myLink.
> In this case, it could be fixed by adding MyPanel.this to the target *before*
> calling executeImportantWork, in which case you also get something in the
> log, but without stacktrace and on WARN level, namely this: "Component not
> rendered because it was already removed from page", but this is far less
> invasive than the scary stacktrace on ERROR level.
> In other cases, however, it may be more difficult to fix, for example when
> you're not in control of the source code of MyPanel. Sure, one could argue
> that you shouldn't alter the page hierarchy in the executeImportantWork
> method, but usually, there's always a certain edge case where 99% of the
> times, no page hierarchy change occurs, but that 1% of the times, it is
> necessary.
> Wicket is a component based framework, so it should be possible to specify
> components with abstract behaviour and not restrict the user of those
> components in what they can do in the implementation of that abstract
> behaviour, especially since, in this case, it does not lead to any actual
> problems and can safely be ignored with a warning.
> I suggest changing the level of the message to WARN and removing the
> stacktrace.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
