On 04/04/2009, Dhanji R. Prasanna <[email protected]> wrote: > On Sat, Apr 4, 2009 at 10:07 AM, James Strachan > <[email protected]>wrote: > >> >> On 03/04/2009, Bob Lee <[email protected]> wrote: >> > I actually have a plan for this! :-) >> > >> > We can't expose a binding to the injection listener. The listener only >> knows >> > about injectable types which are orthogonal to bindings. >> >> OK - I thought that creating an instance to pass into the >> InjectionListener would have used the binding to know if it should >> even bother creating an instance. I'll take your word for it though >> :-) >> >> > >> > My plan is to make singleton scope overridable in Guice 2 (using >> > Modules.override() internally). Then, you can bind your own singleton >> scope >> > implementation that has a destroy() method and looks for @PreDestroy >> > methods. This will work for all singletons, not just those annotated >> > with >> > @Singleton. >> >> Would this approach only work for singleton? What about other scopes >> like request/session/conversation/test or other wacky scopes folks >> might use? >> >> >> > Ideally, we'd have a callback on the Scope interface so we could tell an >> > impl at initialization time about all of the bindings in that scope (and >> you >> > could validate the types, etc.), but this will have to wait for Guice 3. >> >> Would it be so bad for a Scope to have an iterate() method so tools & >> frameworks could iterate through all the objects that have been >> created in a scope? > > > This would make Scope source incompatible with all Guice 1.0 and > transitional code. =(
How would a Scope optionally implementing Iterable cause a problem? > > Also, the way we have designed most scopes now, scope closure is internal to > the scope Understood - it would be up to the scope to figure out how to iterate through whatever data structure it's using to cache instances. But there always is some structure right (apart from NO_SCOPE) - it could be Http request/session stuff or walking the injectors bindings for application scope - but a scope must know how to find an object for a key right? Like collections, it would be fine having this an optional feature - over time I hope we could figure out how to implement it for most implementations? > (or perhaps completely orthogonal as in the case of GuiceFilter, > where the Filter is totally agnostic to the scope). I think there's a happy > compromise with registration of scoped elements using an injection listener > or a (re)bound scope. > > Dhanji. > > > > -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
