I was always just talking about using vanity urls for incoming requests, not for url rewriting of outputed html. I don't have any real desire for rewriting urls on their way out.
However, conceptually speaking I would think you could overcome your "response already committed" problem by overloading the HttpServletResponse object and providing a buffered implementation instead. That way all the rendering that goes on via servlets, jsps, etc is just being written to a buffer and not actually flushed to the client. This would give you the opportunity to inspect the buffer after everyone else is done with it and then do your url rewriting before sending anything back to the client. -- Allen On Fri, 2006-03-03 at 05:18, John Hoffmann wrote: > I had tried to implement HTML rewriting in a servlet filter to alter its > URL's about 2 years ago. The exercise was foiled by error messages > stating that the response had already been commited to the browser. So > somewhere in the code, something had triggered a flush of the buffer. I > have since run into the same problem in other apps, so in my experience, > an outbound filter is almost impossible to use unless you have written > the entire codebase from hand. > > -John > > Sean Gilligan wrote: > > > Matt Raible wrote: > > > >> The URL Rewrite filter can do any URL finagling we need to do. We > >> probably don't take advantage of this library as much as we should. > >> Of course, since it's GPL, we'll likely have to rewrite everything > >> because of it's "viral" license. ;-) > > > > > > Has anyone done anything significant with this filter and Roller? Is > > there a demo/documentation of the results? > > > > I suppose the Rewrite filter would need to filter the outgoing pages > > to rewrite any links in the HTML to the new URLs, right? > > > > -- Sean > >
