As you rightly point out one of the issues with the existing API servlets is
they dont allow for cross-cuts so that implementers can introduce logging
features and statistics gathering. How do you feel about some refactoring
love in the servlets rather than stashing the POST body away which you would
have to re-parse?

On Wed, Sep 3, 2008 at 7:31 PM, Robert Evans <[EMAIL PROTECTED]> wrote:

> I'm interested in logging the types of requests that get processed by
> our implementation of OpenSocial. For instance, in the jsonrpc
> requests, I want the 'method' property of the post body so that I can
> see how many of each type of request we are handling at the point when
> my logger gets called.
>
> On Wed, Sep 3, 2008 at 6:20 PM, Louis Ryan <[EMAIL PROTECTED]> wrote:
> > Just out curiosity what are you interested in logging?
> >
> > On Wed, Sep 3, 2008 at 5:53 PM, Robert Evans <[EMAIL PROTECTED]>
> wrote:
> >
> >> I'd like to log parts of the post body at the end of the request
> >> handling. The way it's currently being done, the servlet pulls the
> >> content out of the post body stream, instantiates json objects from
> >> it, and throws it away. The stream on the request can't be reset,
> >> because it wasn't marked, and hence the post body content is no longer
> >> available.
> >>
> >> I see two options to retain the post body:
> >>
> >> 1) (Token bad suggestion) Have a servlet filter that marks the stream,
> >> reads the stream, grabs off what it wants, makes a request attribute
> >> and then resets the stream for later processing by the JsonRpcServlet.
> >> Sounds redundant and inefficient as it has the stream being read
> >> twice.
> >>
> >> 2) (What I propose) Have a servlet filter that reads the stream, and
> >> stashes the post body as a request attribute in a filter. Modify
> >> JsonRpcServlet to retrieve the attribute the same way that my
> >> end-of-request logging will once the post body as attribute is
> >> available.
> >>
> >> Is this cool with everyone? If so, I can whip up a patch. Other
> >> suggestions are welcome if it is not.
> >>
> >> Thanks,
> >> Bob Evans
> >>
> >
>

Reply via email to