If you want to get to the bottom of that CME, then I'd investigate usage #1 since you've presented usages #2 and #3 and they look okay (barring a Wicket bug).
In any case, I haven't been working with 1.5 very long but for what it's worth we have this as our custom RequestCycleListener: http://pastebin.com/SnS9PS8N Note that returning null allows Wicket to employ the registered PageExpiredErrorPage and AccessDeniedPage pages, and we set both to our Login page. The ErrorPage is our customized "oops" page for truly unexpected exceptions. On Wed, Dec 7, 2011 at 1:36 PM, Fang Lin <fang...@u.washington.edu> wrote: > Hi Dan, > > > > Thanks for the response and the question! > > > > I have put exception handler in three places: > > > > 1. In the WebPage via a try and catch > > > > 2. In the custom RequestCycleListener > > > 3. In the ApplicationSettings > > > > Because I wasn't clear about the relationship between them, I put them > everywhere just in case. I was also wondering why handler got invoked twice. > > > > It looks like #2 and #3 are unnecessary/redundant unless they handles > different exceptions. > > What would be the recommended approach for exception handling? > > > > -Fang > > -----Original Message----- > From: Dan Retzlaff [mailto:dretzl...@gmail.com] > Sent: Wednesday, December 07, 2011 9:40 AM > To: users@wicket.apache.org > Subject: Re: ConcurrentModificationException > > > > Hi Fang, > > > > Are there any other references to SessionErr page in your application aside > > from its registration in ApplicationSettings? I ask because, as Martin > > says, Wicket will only instantiate the PageExpiredErrorPage as a default > > behavior if a custom RequestCycleListener does not provide an alternate > > handler. Since your RequestCycleListener *always* provides a handler, I > > don't see how the default behavior can apply. > > > > Even more confusing is how you can get CME at that location. It's like the > > SessionErr instantiation happens during the detach process. I'm just not > > seeing how Wicket can do that itself. > > > > Dan > > > > On Tue, Dec 6, 2011 at 4:47 PM, Fang Lin <fang...@u.washington.edu> wrote: > > > > > Should I use scheduleRequestHandlerAfterCurrent instead of > > > replaceAllRequestHandlers ? > > > > > > -----Original Message----- > > > From: Fang Lin [mailto:fang...@u.washington.edu] > > > Sent: Tuesday, December 06, 2011 3:39 PM > > > To: users@wicket.apache.org > > > Subject: RE: ConcurrentModificationException > > > > > > I have just run into the ConcurrentModificationException on my dev > server. > > > Not that I can reproduce it, but I got more details: > > > > > > 1. my session has expired > > > > > > 2. the PageExpiredErrorPage SessionErr was invoked. Internally it > > > executed this statement: > > > public SessionErr () > > > { > > > super (); > > > log.info ("Before replaceAllRequestHandlers"); > > > getRequestCycle().replaceAllRequestHandlers (new > SessionErrHandler()); > > > // <=========== > > > } > > > > > > 3. SessionErrHandler was created, > > > public SessionErrHandler() > > > { > > > super(LOG_BACKIN_URL); > > > log.info ("RedirectRequest"); > > > } > > > > > > Log: > > > INFO 06 15:23:58.755 Before replaceAllRequestHandlers [m.p.SessionErr] > > > INFO 06 15:23:58.755 RedirectRequest [m.SessionErrHandler] INFO 06 > > > 15:23:58.760 Before replaceAllRequestHandlers [m.p.SessionErr] INFO 06 > > > 15:23:58.760 RedirectRequest [m.SessionErrHandler] > > > > > > On the browser, HTTP Status 500 - > > > java.util.ConcurrentModificationException > > > > > > java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) > > > java.util.AbstractList$Itr.next(AbstractList.java:343) > > > > > > > > org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerStack.java:176) > > > > > > > org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:565) > > > > > > > org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:508) > > > > > > > > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:284) > > > > > > > > org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162) > > > > > > > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218) > > > > > > -----Original Message----- > > > From: Fang Lin [mailto:fang...@u.washington.edu] > > > Sent: Tuesday, December 06, 2011 2:06 PM > > > To: users@wicket.apache.org > > > Subject: RE: ConcurrentModificationException > > > > > > I have been trying to reproduce it on our dev server this morning, but > > > could not. However I did run into it twice on our production server > > > yesterday. > > > > > > I wonder if you could answer my question "Is this exception handler > > > invoked before or after the ErrorPages ?" > > > > > > -----Original Message----- > > > From: Martin Grigorov [mailto:mgrigo...@apache.org] > > > Sent: Tuesday, December 06, 2011 12:47 PM > > > To: users@wicket.apache.org > > > Subject: Re: ConcurrentModificationException > > > > > > No, I don't see anything wrong here. > > > If you are able to reproduce it then we can debug it. > > > > > > On Tue, Dec 6, 2011 at 9:40 PM, Fang Lin <fang...@u.washington.edu> > wrote: > > > > Thanks, Martin! > > > > > > > > In the init(), I have: > > > > { > > > > getMarkupSettings().setStripWicketTags(true); > > > > > > > > IApplicationSettings settings = getApplicationSettings(); > > > > settings.setAccessDeniedPage(AccessErr.class); > > > > settings.setPageExpiredErrorPage(SessionErr.class); > > > > settings.setInternalErrorPage(InternalErr.class); > > > > > > > > // #2 starts > > > > getRequestCycleListeners().add(new AbstractRequestCycleListener() > > > > { > > > > > > > > public IRequestHandler onException(RequestCycle cycle, > > > > Exception e) > > > > { > > > > return new RedirectRequestHandler (ERROR_PAGE_URL); > > > > } > > > > }); > > > > // #2 ends > > > > } > > > > Could the #2 code block be the cause? Is this exception handler > invoked > > > before or after the ErrorPages ? > > > > > > > > Our authentication strategy is set up at Apache level. > > > > This is what SessionErr class does: > > > > getRequestCycle().replaceAllRequestHandlers (new SessionErrHandler()); > > > > > > > > And SessionErrHandler redirect to the Login Servlet. And the Login > > > Servlet will be routed to the WebLogin server. > > > > > > > > -----Original Message----- > > > > From: Martin Grigorov [mailto:mgrigo...@apache.org] > > > > Sent: Monday, December 05, 2011 11:59 PM > > > > To: users@wicket.apache.org > > > > Subject: Re: ConcurrentModificationException > > > > > > > > Hi, > > > > > > > > I don't see how this may happen. > > > > The execution of RequestCycle is single threaded. > > > > Do you have RequestCycleListener or something similar where you start > > > another thread and you use the same instance of RequestCycle ? > > > > > > > > On Tue, Dec 6, 2011 at 2:31 AM, Fang Lin <fang...@u.washington.edu> > > > wrote: > > > >> When clicking on a link (i.e., ?5-1.ILinkListener-...) after a session > > > expired, this error page shows up on my browser window: > > > >> Exception report > > > >> message > > > >> description The server encountered an internal error () that prevented > > > it from fulfilling this request. > > > >> exception > > > >> java.util.ConcurrentModificationException > > > >> > > > >> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:3 > > > >> 7 > > > >> 2) > > > >> > > > >> java.util.AbstractList$Itr.next(AbstractList.java:343) > > > >> > > > >> org.apache.wicket.request.RequestHandlerStack.detach(RequestHandlerSt > > > >> a > > > >> ck.java:176) > > > >> > > > >> org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.ja > > > >> v > > > >> a:565) > > > >> > > > >> org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java: > > > >> 508) > > > >> > > > >> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach( > > > >> R > > > >> equestCycle.java:284) > > > >> > > > >> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFil > > > >> t > > > >> er.java:162) > > > >> > > > >> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.ja > > > >> v > > > >> a:218) > > > >> at > > > >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl > > > >> i > > > >> cationFilterChain.java:235) > > > >> at > > > >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF > > > >> i > > > >> lterChain.java:206) > > > >> at > > > >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV > > > >> a > > > >> lve.java:233) > > > >> at > > > >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextV > > > >> a > > > >> lve.java:191) > > > >> at > > > >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j > > > >> a > > > >> va:127) > > > >> at > > > >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j > > > >> a > > > >> va:102) > > > >> at > > > >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal > > > >> v > > > >> e.java:109) > > > >> at > > > >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav > > > >> a > > > >> :298) > > > >> at > > > >> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) > > > >> at > > > >> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) > > > >> at > > > >> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:774) > > > >> at > > > >> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.ja > > > >> v > > > >> a:703) > > > >> at > > > >> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSock > > > >> e > > > >> t.java:896) > > > >> at > > > >> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP > > > >> o > > > >> ol.java:690) > > > >> at java.lang.Thread.run(Thread.java:662) > > > >> This ConcurrentModificationException occurs about 70+ times on an > > > application server daily. > > > >> Wicket version 1.5.3. > > > >> Any suggestion on how to avoid this? > > > >> In the init method of sub-class of the WebApplication , I have: > > > >> IApplicationSettings settings = getApplicationSettings(); > > > >> settings.setAccessDeniedPage(AccessErr.class); > > > >> settings.setPageExpiredErrorPage(SessionErr.class); > > > >> settings.setInternalErrorPage(InternalErr.class); > > > >> When a session expired, should it invoke the PageExpiredErrorPage? > > > > > > > > Yes. You make a request to a page, Wicket searches for this page in the > > > stores, doesn't find it and throws PageExpiredException. > > > > But, if the request url has the mount path then Wicket will create a > new > > > Page instance instead. If you have authentication strategy set up then > you > > > go to the Login page, otherwise this page will be rendered. > > > > > > > > If you are able to reproduce the problem in a quickstart attach it to > > > Jira so we can debug it. > > > > Thanks! > > > > > > > >> -Fang > > > >> > > > >> > > > > > > > > > > > > > > > > -- > > > > Martin Grigorov > > > > jWeekend > > > > Training, Consulting, Development > > > > http://jWeekend.com > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > > > > > > > > > -- > > > Martin Grigorov > > > jWeekend > > > Training, Consulting, Development > > > http://jWeekend.com > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > >
