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? Like the Collections framework an implementation could throw an unsupported exception if the developer found it too hard to implement? (or implementing Iterable could be optional - or a scope could return an empty iterator). I could imagine tools might find it handy being able to easily enumerate the objects that have been created in a scope. Eg for tuning, knowing the request scoped objects created might be handy? As an added bonus anyone can then write any kind of close mechanism on any kind of scope easily with minimal changes to guice? It's a while since I did my original lifecycle patch so my memory is hazy (and am on my cell now so can't easily check the code :-) but I seem to remember enumerating request/session/test style scopes was easy - though singleton was quite hard - purely due to very deep nesting of implementation classes. > > Bob > > On Fri, Apr 3, 2009 at 5:20 AM, James Strachan > <[email protected]>wrote: > >> >> So after Dhanji's great suggestion... >> http://code.google.com/p/google-guice/issues/detail?id=62 >> >> I started trying to implement a pre destroy hook using the injectable >> type hooks. The idea being that if a type has a method annotated with >> @PreDestroy (or whatever the close hook is - e.g. its >> DisposableBean.destroy() in Spring), we register a handler into some >> 'close handler' object in the same scope (assuming >> application/request/session scopes etc). >> >> The problem is, there's no way to really know for sure what scope the >> type/injectee is in. Well we could filter all objects which are >> annotated with @Singleton and add the hook for those and repeat for >> each scope annotation. The problem is that would not fire for objects >> bound to a scope using the module code. e.g. >> >> bind(Foo.class).in(Singleton.class); >> >> As Foo might not be annotated with Singleton.class in this case >> >> I wonder if the InjectionListener should also expose the Binding as >> well (which has its Scoping?). Scoping is currently not on the Binding >> interface but is on BindingImpl (and I don't mind a hacky cast now and >> again :). Maybe we should add getScopeAnnotation() to Binding? >> >> Another problem I have is that given the injectee I've got to look up >> the 'close handler' object for the same scope as the injectee so I can >> register the handler into the right scope. A scope annotation isn't a >> binding annotation, so I can't do >> getProvider(Key.get(CloseHandler.class, someScopeAnnotation)). >> >> However if I can find the scope annotation for the injectee, I can >> then try to get all the bindings for the "close handler" type - then >> find the one with the same scope annotation - then use that one. >> >> You'd hope scopes are fairly small in number; so I could create a sub >> class "close handler" for each scope and annotate it with the scope >> annotation, then look that up; then I just need to keep a map of scope >> annotations to the sub type of the close handler. It'd work around >> some limitations; though its a tad icky in that its now hard coded to >> the number of scope annotations out there. >> >> I just wondered if folks had any other cunning ideas to implement this >> in a less sucky way? >> >> Exposing the binding to the injectee / InjectionListener seems >> necessary really; to avoid only implementing types with a scope >> annotation. >> >> >> Or another approach is to just apply some kind of patch like I >> submitted before - so there's basically some kinda way to iterate >> through all the objects in a scope; afterall each scope stores the >> objects in its scope - being able to iterate through those does seem >> way simpler and more extensible. >> >> Thoughts? >> >> -- >> James >> ------- >> http://macstrac.blogspot.com/ >> >> Open Source Integration >> http://fusesource.com/ >> >> > >> > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
