I've noticed in Guice's docs, there is advice *not* to write custom scopes. Being a bit of a rebel, I read that a couple of years ago and immediately wrote a library to make writing solid, reliable custom scopes trivial :-) -
http://bit.ly/UIbOkW
This has been very handy in writing a little framework that attempts to make writing asynchronous web apps with Netty easy. Logic is decomposed into small reusable chunks which get chained together, where each one, in its constructor, can provide an array of objects that are merged into the current scope (becoming potential constructor arguments to the next chunk). So responding to a request is really a list of classes, each of which has a chance to provide some objects for injection into the next one in the chain - the framework hides all of the plumbing of that, so you're just using @Inject and writing what feels like and is straightforward Guice code. For the asynchronous part, you can wrap an ExecutorService in a delegate provided by a custom scope, so that you pay a little in memory, but can transparently submit Callables and Runnables to an ExecutorService and the exact state of the scope will be reconstituted before the Runnable or Callable is executed - which takes care of the fact that the whole point is to be actually asynchronous. So you basically just have a scope that is able to be entered recursively a bunch of times adding more objects into the scope.
Anyway, all of this has been working very nicely and I've got an app or two in production with it, and I'm wondering: Is the advice against custom scopes because there is some hidden cost to using them, or just because it's easy to screw up writing them?
Thanks,
Tim