Wicket
  1. Wicket
  2. WICKET-3832

RequestLogger doesn't log incoming event and outgoing page

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5-RC4
    • Fix Version/s: 1.5-RC6
    • Component/s: wicket
    • Labels:
      None

      Description

      The requestlogger currently doesn't log the incoming request and the outgoing page, which it did in 1.4.x (and earlier). This is due to

      getRequestLogger().logEventTarget(handler);
      getRequestLogger().logResponseTarget(handler);

      not being called. This results in log entries like:

      [2011-06-22 11:43:20,836] [TP-Processor6] RequestLogger | time=12,event=null,response=null,sessioninfo=...

      which isn't saying much, and making every presentation I gave on the RequestLogger, and chapter 14 from WiA look foolish

      1. wicket-3832.patch
        8 kB
        Martin Grigorov

        Activity

        Hide
        Martijn Dashorst added a comment - - edited

        Solved

        Show
        Martijn Dashorst added a comment - - edited Solved
        Hide
        Martijn Dashorst added a comment -

        There were a couple more issues with the request logger implementation. It used getPage() to log the page class and page id: causing page instantiations at wrong times. This has been remedied by requiring an extra method to provide the page id (if present). The page instantiation caused problems with the Swarm/Wasp security framework.

        Further more the request logger now logs the requested URL as well.

        Show
        Martijn Dashorst added a comment - There were a couple more issues with the request logger implementation. It used getPage() to log the page class and page id: causing page instantiations at wrong times. This has been remedied by requiring an extra method to provide the page id (if present). The page instantiation caused problems with the Swarm/Wasp security framework. Further more the request logger now logs the requested URL as well.
        Hide
        Martin Grigorov added a comment -

        This should get you started.

        Show
        Martin Grigorov added a comment - This should get you started.
        Hide
        Martin Grigorov added a comment -

        This is what the wiki page I mentioned in my earlier comment does.

        Show
        Martin Grigorov added a comment - This is what the wiki page I mentioned in my earlier comment does.
        Hide
        Igor Vaynberg added a comment -

        using a request cycle listener:

        the target page can be identified by examining the first handler resolved - ie the first call to onRequestHandlerResolved()

        the result page can be identified as the last ipagerequesthandler set - so the last call to onRequestHandlerResolved() where handler is an ipagrequesthandler

        Show
        Igor Vaynberg added a comment - using a request cycle listener: the target page can be identified by examining the first handler resolved - ie the first call to onRequestHandlerResolved() the result page can be identified as the last ipagerequesthandler set - so the last call to onRequestHandlerResolved() where handler is an ipagrequesthandler
        Hide
        Martijn Dashorst added a comment -

        My issue is identifying the page that was the target of the incoming event, and the page that was rendered as the final response. This way we have 1.4 parity in functionality.

        I agree that we should strive to improve our request logging and exposing more detail. What we are more interested in rather than the guts is how long the event part took and how long the rendering part. So from the start of the request until the end of onClick for example, and from the end of onClick to the end of request. That would make identifying the slow pages/requests much easier. Now it is hard to discern whether the event handler was slow or the page construction/rendering.

        Show
        Martijn Dashorst added a comment - My issue is identifying the page that was the target of the incoming event, and the page that was rendered as the final response. This way we have 1.4 parity in functionality. I agree that we should strive to improve our request logging and exposing more detail. What we are more interested in rather than the guts is how long the event part took and how long the rendering part. So from the start of the request until the end of onClick for example, and from the end of onClick to the end of request. That would make identifying the slow pages/requests much easier. Now it is hard to discern whether the event handler was slow or the page construction/rendering.
        Hide
        Igor Vaynberg added a comment -

        request handlers are not that opaque. they implement interfaces that expose their underbelly. eg: IPageRequestHandler, IComponentRequestHandler.

        in the name of better logging why dont we create a IIntrospectableRequestHandler

        { Map<String,Object> introspect(); }

        the logger can then check if a request handler implements this and get the key/value pairs (or some other format) of details and log them. if the handler does not implement this interface the logger can show a warning.

        what would be interesting if perhaps we allowed the return data to be a tree of key/value pairs - like json. and then collect and render it in the debugbar.

        Show
        Igor Vaynberg added a comment - request handlers are not that opaque. they implement interfaces that expose their underbelly. eg: IPageRequestHandler, IComponentRequestHandler. in the name of better logging why dont we create a IIntrospectableRequestHandler { Map<String,Object> introspect(); } the logger can then check if a request handler implements this and get the key/value pairs (or some other format) of details and log them. if the handler does not implement this interface the logger can show a warning. what would be interesting if perhaps we allowed the return data to be a tree of key/value pairs - like json. and then collect and render it in the debugbar.
        Show
        Martin Grigorov added a comment - See https://cwiki.apache.org/confluence/display/WICKET/RequestCycle+in+Wicket+1.5
        Hide
        Martijn Dashorst added a comment - - edited

        I'd like to solve this issue, but the handlers are a bit opaque for me as to how they relate to events and responses. Giving pointers on where to hook into Wicket would be awesome. I'm currently toying with RequestCycleListener, but not sure if that will solve my issues.

        Show
        Martijn Dashorst added a comment - - edited I'd like to solve this issue, but the handlers are a bit opaque for me as to how they relate to events and responses. Giving pointers on where to hook into Wicket would be awesome. I'm currently toying with RequestCycleListener, but not sure if that will solve my issues.

          People

          • Assignee:
            Martijn Dashorst
            Reporter:
            Martijn Dashorst
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development