[
https://issues.apache.org/jira/browse/WICKET-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223048#comment-14223048
]
Andrea Del Bene commented on WICKET-5773:
-----------------------------------------
The problem is that on client side JavaScript keeps sending requests every
second while the server side is stuck on breakpoint. Once you let the
application continue, the server receives the client requests but since there
is no more the correspondig behavior you get the exception above.
I don't see an easy solution for this. You should simply call stop/restart
methods of AbstractAjaxTimerBehavior to decide when the behavior should be
active or not. Stop method can be called just after you have added the behavior
to a component passing a null parameter. In this way the behavior is initially
disabled.
> Removal of AjaxTimerBehavior throws InvalidBehaviorIdException
> --------------------------------------------------------------
>
> Key: WICKET-5773
> URL: https://issues.apache.org/jira/browse/WICKET-5773
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.16.0, 6.18.0
> Reporter: Krys Malak
> Attachments: myproject.zip
>
>
> Under the following setup we get an exception in our project:
> Component with an AbstractAjaxTimerBehavior with a simple Model. Two Links
> that change the model value and execute "ajaxRequestTarget.add" on this
> component. Depending on the model value the timerBehavior is added or removed
> to the component.
> See the enclosed Quickstart: Step to reproduce in Application started in
> Debug. Breakpoint set in "onConfigure" of Component:
> Click Link2. Timer Behavior is firing every second.
> Click Link1. Hold on Breakpoint in "onConfigure" and let the application
> continue.
> -> org.apache.wicket.behavior.InvalidBehaviorIdException
> In rare cases, it is possible to reproduce this behavior without a
> breakpoint, but with the breakpoint it is reporduceable every time. I could
> not write a test (in debug or normal) that shows the same behavior.
> Exception:
> Last cause: Cannot find behavior with id '0' on component
> 'com.mycompany.HomePage$1:container' in page '[Page class =
> com.mycompany.HomePage, id = 0, render count = 1]'. Perhaps the behavior did
> not properly implement getStatelessHint() and returned 'true' to indicate
> that it is stateless instead of returning 'false' to indicate that it is
> stateful.
> Stack:
> Root cause:
> org.apache.wicket.behavior.InvalidBehaviorIdException: Cannot find behavior
> with id '0' on component 'com.mycompany.HomePage$1:container' in page '[Page
> class = com.mycompany.HomePage, id = 0, render count = 1]'. Perhaps the
> behavior did not properly implement getStatelessHint() and returned 'true' to
> indicate that it is stateless instead of returning 'false' to indicate that
> it is stateful.
> at org.apache.wicket.Behaviors.getBehaviorById(Behaviors.java:316)
> at org.apache.wicket.Component.getBehaviorById(Component.java:4470)
> at
> org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:249)
> at
> org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:236)
> at
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:862)
> at
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
> at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:261)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:218)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289)
> at
> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259)
> at
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201)
> at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:443)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:556)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:369)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:486)
> at
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:933)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:995)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)
> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
> at
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
> at
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:724)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)