[
https://issues.apache.org/jira/browse/WICKET-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802443#action_12802443
]
Kirill commented on WICKET-2690:
--------------------------------
I investigated that. While I didn't discover anything interesting (the
initializers run as expected), after the investigation the problem MAGICALLY
DISAPPEARED. I then checked out the project in its previous state into /tmp,
and I can't reproduce the problem using that project, either. So it turns out
either NetBeans, or Tomcat is to blame (I have also reinstalled the latter,
unfortunately deleting the previous install). Yet it is complete mystery to me,
how could any of them achieve this kind of disutility.
Will reopen the issue if something else turns up...
> Stateless components and classloading
> --------------------------------------
>
> Key: WICKET-2690
> URL: https://issues.apache.org/jira/browse/WICKET-2690
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.5
> Reporter: Kirill
>
> Following a post on the user list, which so far got no reply, posting the
> issue here:
> Wicket 1.4.5 with Tomcat 6.0.
> I'm trying to make a session-resistant (but *not* bookmarkable) link on the
> homepage that should work no matter if the page exists. If the page doesn't
> exist, I want it to be created and then the link event handler invoked. As
> far as I understand, StatelessLink should work for this purpose. However, I
> can't get it to work. From time to time, clicking it produces the following
> error in the console:
> SEVERE: unable to find listener interface ILinkListener
> org.apache.wicket.WicketRuntimeException: unable to find listener interface
> ILinkListener
> at
> org.apache.wicket.request.target.component.BookmarkableListenerInterfaceRequestTarget.processEvents(BookmarkableListenerInterfaceRequestTarget.java:159)
> at
> org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
> at
> org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
> at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
> at
> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
> at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:390)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
> at java.lang.Thread.run(Thread.java:619)
> Sometimes I also get the following (seemingly related) error:
> org.apache.wicket.protocol.http.request.InvalidUrlException:
> org.apache.wicket.WicketRuntimeException: Unable to instantiate Page class:
> com.my.HomePage. See below for details.
> at
> org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:262)
> at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
> at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
> at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
> at
> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
> at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:390)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: org.apache.wicket.WicketRuntimeException: Unable to instantiate
> Page class: com.my.HomePage. See below for details.
> at
> org.apache.wicket.request.AbstractRequestCycleProcessor.resolveBookmarkablePage(AbstractRequestCycleProcessor.java:286)
> at
> org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:78)
> ... 20 more
> Caused by: org.apache.wicket.WicketRuntimeException: Attempt to access
> unknown request listener interface ILinkListener
> at
> org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCycleProcessor.java:407)
> at
> org.apache.wicket.request.AbstractRequestCycleProcessor.resolveBookmarkablePage(AbstractRequestCycleProcessor.java:266)
> ... 21 more
> A reliable way to reproduce it is:
> 1) open the home page in the browser
> 2) restart the web application in Tomcat
> 3) click the link
> Every time I perform the above steps, I either get the first exception, or
> the second.
> It doesn't necessarily happen immediately when the session expires (but
> AFAICT it always happens some time after that). Looks like it happens when a
> classloader cache in the servlet container gets garbage-collected.
> I find the first stack trace especially interesting. I have traced the
> execution flow in debugger, and I'm confident that the first exception always
> happens after some Links get instantiated, and because Link implements
> ILinkListener, at that point the RequestListenerInterface instance for
> ILinkListener exists. However, RequestListenerInterface.register() method
> doesn't get called during the "resolve" step, so I must conclude that the
> servlet container uses the preexisting class at that point. But when the
> execution flow reaches AbstractRequestCycleProcessor.java:92 during the
> "process" step, the RequestListenerInterface instance for ILinkListener can
> no longer be found.
> Such inconsistencies happen when one class (AbstractRequestCycleProcessor?)
> is created by a different classloader than another class
> (RequestListenerInterface?).
> What remains unclear is why I can't see other reports of the same problem on
> the list. Am I doing something wrong?
> From what I know about servlet containers, you are not supposed to mess with
> classloading there. I did some of that in past, and it can be VERY hard to
> make it work across the implementations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
