In addition to what Rhett said ... one massively huge benefit of having Resources that are created per-request is that they need not be thread safe. Very few developers (:: cough :: except Tim) can do concurrency correctly every time.
But I've spent most of the afternoon noodling over this discussion and wondering why the Resource construction issue has never really bugged me like it bugs Tal. I guess I just have never written Resources that have a lot of of local configuration state. This might be because I'm not an IoC/DI guy by default -- it's a tool I use sometimes, but not a fundamental way of thinking for me. It may also help to know that I tend to like functional programming a lot, and tend to avoid static fields in general; I fear the bite of class loader hierarchies I didn't expect. For the higher-level configuration stuff, I tend to dynamically fetch it from the Application itself (which of course is wired-in and long-lived) or the Context. Really, this isn't noticeably costly. I'm not in opposition to more ways of constructing a Resource. But I also feel, somewhere in my bones, that if Resources really chafe at the existing model, they /probably/ can be refactored or redesigned to be a much smoother fit, without losing anything important ... but just thinking differently. I would be willing to have a look at a concrete case -- e.g. a resource in the scripting extension -- and try to make a proposal if one fits. Then we could talk about it in code review specifics and not in general architectural chalk talk. - R On Mon, Mar 23, 2009 at 4:08 PM, David Bordoley <bordo...@gmail.com> wrote: > Out of curiosity is there a reason why Resource isn't implemented as a > subclass of Restlet? It seams like there is a lot of overhead in > initializing a new Resource on every request especially when a lot of > salient features such as what methods,variants, etc that are supported > tend to static for a give route to that resource. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1394971
