The separation between the (org.restlet) API and (com.noelios.restlet) RI means that you can write API compliant code that runs under a different implementation. I think Restlet's ServerServlet is the easiest way to go, though, you will need much less plumbing.
I was thinking more of a "gutted" version of your security filter -- one that just checks nothing and spits out some static values (username, common name, whatever else it supplies) in an analogous fashion. Without that info, I don't know what you need to map onto RESTful concepts -- if anything. Maybe just letting them through the filter (or not) is enough, and your Restlet code doesn't need to know anything at all about the filter's processing. - Rob On Thu, Jul 31, 2008 at 1:04 PM, mshaffer55 <[EMAIL PROTECTED]> wrote: > I'll think about providing an anonymized version of our security filter > code, > but meanwhile, another question occurs to me. I was assuming that we have > to use > the Restlet servlet, but maybe that's not actually true? Our existing > servlet is > a controller that dispatches to different server code paths based on > tearing > apart the request URL. I'm wondering if our Restlet code could just become > one > or more of these code paths, and so we would not use the Restlet servlet at > all? > If so, would we still have to inject security-related information into the > Restlet world somehow? > > >
