Yes - you may want to enable the request logger in development so that it
will show you exactly what each request is.  For instance, if you add a CSS
file, an image, etc, each of those is a separate request.

Add this in your Application.init() :

        getRequestLoggerSettings().setRequestLoggerEnabled(true);

You'll get very helpful output like this:

2008-08-14 11:22:17,175 [btpool0-10] INFO -
time=96,event=BookmarkablePage[com.somecompany.web.wicket.pages.Home],response=BookmarkablePage[com.somecompany.web.wicket.pages.Home],sessionid=1mzv3ov7qclgr,sessionsize=697161,sessionstart=Thu
Aug 14 11:21:38 CDT
2008,requests=4,totaltime=65784,activerequests=2,maxmem=904M,total=439M,used=257M

2008-08-14 11:22:17,245 [btpool0-9] INFO -
time=1,event=null,response=[ResourceStreamRequestTarget[resourceStream=file:/home/myname/coding/somecompany/thf.site.java/target/classes/com/somecompany/web/wicket/site.css,fileName=null],sessionid=1mzv3ov7qclgr,sessionsize=696304,sessionstart=Thu
Aug 14 11:21:38 CDT
2008,requests=5,totaltime=65785,activerequests=2,maxmem=904M,total=439M,used=262M

2008-08-14 11:22:17,249 [btpool0-9] INFO -
time=0,event=null,[EMAIL 
PROTECTED],fileName=null],sessionid=1mzv3ov7qclgr,sessionsize=696304,sessionstart=Thu
Aug 14 11:21:38 CDT
2008,requests=6,totaltime=65785,activerequests=2,maxmem=904M,total=439M,used=262M


-- 
Jeremy Thomerson
http://www.wickettraining.com

On Thu, Aug 14, 2008 at 9:45 AM, Igor Vaynberg <[EMAIL PROTECTED]>wrote:

> things like Image components or any other component non-page component
> that is served by wicket will trigger onbeginrequest...
>
> -igor
>
> On Thu, Aug 14, 2008 at 12:19 AM, Benny Weingarten
> <[EMAIL PROTECTED]> wrote:
> >
> > Some pages trigger the onBeginRequest() method in my RequestCycle around
> 3-4
> > times, others even 10 times. The number is constant for each page, i.e.
> for
> > PageA, the number of calls is always 5, and for PageB the number of calls
> is
> > always 8 (though, I haven't monitored the number of executions closely -
> the
> > number may be different between the first time a page is invoked, and
> > subsequent times).
> >
> > The way I monitor the number of calls is a simple system.out.println call
> > here:
> >
> > public class MyRequestCycle extends WebRequestCycle {
> >
> >        public MyRequestCycle(MyApp application, WebRequest request,
> >                        Response response) {
> >                super(application, request, response);
> >        }
> >
> >        @Override
> >        protected void onBeginRequest() {
> >                System.out.println("On begin request called!");
> >        }
> > }
> >
> >
> > I wonder if the complexity of a page should have any affect on the number
> of
> > calls to  RequestCycle.onBeginRequest()? if a page has many panels and
> those
> > panels in turn have even more nested panels....?
> >
> >
> >
> > thanks,
> > Benny.
> >
> > igor.vaynberg wrote:
> >>
> >> by numerous you mean two?
> >>
> >> by default wicket uses something similar to redirect-after-post so
> >> after you click a link there is a http redirect to a view-url that
> >> will no longer execute the link. so that is two http requests/two
> >> request cycles.
> >>
> >> -igor
> >>
> >> On Wed, Aug 13, 2008 at 7:18 AM, Benny Weingarten <
> [EMAIL PROTECTED]>
> >> wrote:
> >>>
> >>> Thanks Igor.
> >>>
> >>> I have done that, and it is exactly what I was looking for.
> >>>
> >>> However, I have noticed something that strikes me odd:
> >>> on every request to render a page in my application (every time I click
> a
> >>> link in my application to another page in my application), the method
> >>> newRequestCycle() in WebApplication is called numerous times, and
> >>> subsequently, my pre-render actions are performed many times. Is this
> >>> expected? shouldn't one page require only one RequestCycle?
> >>>
> >>> thanks,
> >>> Benny.
> >>>
> >>>
> >>>
> >>>
> >>> igor.vaynberg wrote:
> >>>>
> >>>> create a custom request cycle and put this stuff in
> >>>> requestcycle#onbeginrequest
> >>>>
> >>>> -igor
> >>>>
> >>>> On Sun, Aug 10, 2008 at 11:15 PM, Benny Weingarten
> >>>> <[EMAIL PROTECTED]> wrote:
> >>>>>
> >>>>> Hello.
> >>>>>
> >>>>> I'm writing a wicket application for facebook, but I think my problem
> >>>>> may
> >>>>> be
> >>>>> common to many wicket applications.
> >>>>>
> >>>>> In my case, I'm using the wicket-facebook authentication strategy
> that
> >>>>> is
> >>>>> described in a different thread here on nabble. That works great -
> when
> >>>>> a
> >>>>> page is rendered, the AuthenticationStrategy makes sure that I have a
> >>>>> valid
> >>>>> FacebookRestClient object in my session.
> >>>>> In my application I need to do some other "init" stuff in a service
> >>>>> class,
> >>>>> and I do that in the onUnauthorizedInstantiation method. This "init"
> >>>>> information is stored in a ThreadLocal variable in my
> BACKEND-Service.
> >>>>> This
> >>>>> is an important point, because wicket uses many different threads for
> >>>>> user
> >>>>> requests, so I need to make sure that in the beginning of each render
> >>>>> request, the init information is stored on THAT REQUEST's thread.
> >>>>>
> >>>>> ALL my components in all my pages and panels try to fetch information
> >>>>> from
> >>>>> the BACKEND-Service. If the BACKEND-Service hasn't been initialized
> >>>>> with
> >>>>> the
> >>>>> "init" information on the ThreadLocal variable on the same thread
> that
> >>>>> the
> >>>>> render request is issued on, an exception would be thrown and the
> page
> >>>>> would
> >>>>> fail to render.
> >>>>>
> >>>>> This is all great when a user is browsing through PAGES. However, in
> >>>>> one
> >>>>> page I have a tabbedpanel. When first the user loads the page, the
> >>>>> authorization strategy kicks in, and the init actions are performed,
> >>>>> the
> >>>>> page renders correctly.
> >>>>>
> >>>>> *** and here is my problem:
> >>>>> when the user clicks on the second tab in the page, the request can
> be
> >>>>> made
> >>>>> from a different thread (wicket controls that), but the "init" stuff
> is
> >>>>> not
> >>>>> performed because it is not a new page that needs to be rendered.
> This
> >>>>> problem also arises when I use ajax components.
> >>>>>
> >>>>> I thought of putting the init stuff in the "onBeforeRender()" method
> of
> >>>>> each
> >>>>> separate component that requires the "init" information.
> >>>>>
> >>>>> Would this be the preferred way of doing "init" actions for
> components?
> >>>>>
> >>>>> Thanks,
> >>>>> Benny.
> >>>>> --
> >>>>> View this message in context:
> >>>>>
> http://www.nabble.com/Pre-render-action-common-to-all-pages-tp18920691p18920691.html
> >>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> View this message in context:
> >>>
> http://www.nabble.com/Pre-render-action-common-to-all-pages-tp18920691p18963966.html
> >>> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >
> > --
> > View this message in context:
> http://www.nabble.com/Pre-render-action-common-to-all-pages-tp18920691p18976848.html
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to