Justin Deoliveira ha scritto: > Yeah... tough issue. I think we might be able to get around part of this > by instead of passing in the request object to the exception handler... > passing in the Dispatchers internal Request object, which has the > following information: > > * HttpServletRequest/Response > * Raw kvp + parsed kvp > * a reader for the body content > > Getting the xml in a post is tricky... the requst input stream is > buffered, and marked at 2048 bytes. So that up to that can be ready by > the dispatcher and then reset for the service processing the request.
Friday, almost evening... my head is spinning :) Anyways, looks like a good idea, but the Request objects should become public. If we do that, the same object could also hold the Operation, that is, accumulate information as it goes, and leave the exception handlers figure out what they prefer to use. Yet, is the parsed kvp set if an exception occurs right during kvp parsing? Even in that case there is no guarantee I'd get the widht/height/format in parsed format, I'd have to resort using the kvp parsers manually anyways.... so I would have no much use Operation or the parsed kvp, thought the raw kvp can be handy. > So i guess the exception handler could get at the request if the service > has not read it already... Yeah, this one too seems useful. So ok, exposing Request seems like a good path. So, we move it to its own class? And then add getters and setters for all the fields it has? Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
