I love your efforts, but I wonder if we can have something that has less
impact on core Guice.
Would it be possible to create like a Scope decorator that adds lifecycle
support to a scope?
Scope lifecycleSingleton = Lifecycles.lifecycleScope(Scopes.SINGLETON);
bind(My.class).in(lifecycleSingleton);
And then instead of injector.close, maybe have something like
Lifecycles.destroy(lifecycleSingleton);
Obviously you could provide a class that has the decorated scopes and holds
some utility methods:
class LifecycleScopes {
final Scope LIFECYCLE_SINGLETON =
Lifecycles.lifecycleScope(Scopes.SINGLETON);
...
static final List<Scope> LIFECYCLE_SCOPES;
static {
// add all lifecycle scopes to LIFECYCLE_SCOPES
}
void destroy() {
// for scope in LIFECYCLE_SCOPES:
// scope.destroy();
}
}
Perhaps I'm just being stupid, because I haven't looked at the patch code,
really. But I do think it would be nice if we can keep it as an opt-in
extension, keeping the core API clean.
Robbie
On Mon, Oct 6, 2008 at 3:48 PM, James Strachan <[EMAIL PROTECTED]>wrote:
>
> Since adding a patch for issue 78
> http://code.google.com/p/google-guice/issues/detail?id=78
>
> I've taken a stab at adding support for @PreDestroy and Spring's
> DisposableBean lifecycles; building on top of my previous patch.
>
> So far the close hooks only work with Singleton scoped objects; but
> I've also added the functionality into the REQUEST and SESSION scoped
> Scopes too - though I've not yet added any code to the Servlet package
> to invoke the close() methods yet.
>
> I've introduced a Closeable interface which a Provider can implement
> (and a Scope can return a custom Provider which implements this); so
> if a Scope implements Closeable you can then close it down cleanly;
> ensuring that all objects are closed and each exception thrown is
> collected (rather like we do with the Errors class when binding
> objects).
>
> Also I've added a close() method to Injector so you can close down any
> singleton objects.
>
> e.g.
>
> Injector injector = Guice.createInjector(...);
>
> // do stuff
>
> // now lets cleanly close down the singletons in this injector
> injector.close();
>
>
>
> There are many possible strategies we can use to actually close down
> an object held within a Singleton/REQUEST/SESSION scope . e.g.
> respecting java.io.Closeable; or using @PreDestroy on a method or
> Spring's DisposableBean or some developer-defined lifecycle
> API/annotation mechanism etc.
>
> So I've introduced a strategy interface, Closer which is a
> strategy/adapter to close objects down. So you can bind as many Closer
> implementations into your binder and this patch will invoke them all
> on each object in the scope being closed. e.g. so you could install
> the JavaIO, JSR250 and Spring closers to respect those lifecycles. If
> you look at some of the Closer implementations in this patch it will
> become a bit more clear.
>
> Note this patch has no effect to objects created outside of a
> singleton (and is currently not invoked for REQUEST/SESSION scopes).
>
> The code InjectorImpl.close() and REQUEST/SESSION scopes is fairly
> straightforward. The more complex change was dealing with the
> Singleton scope; as the singleton SINGLETON object creates Providers
> for each key which internally stores the singleton object. So to be
> able to close all the singletons on an injector you need to iterate
> through all the Providers in the bindings looking for providers which
> are Closeable. Since there's a lot of wrapping of Providers along with
> InternalFactory; I made a number of internal wrappers and adapters
> also implement Closeable. This should have no runtime effect when
> folks don't invoke the Injector.close() method.
>
> As an aside - while implementing this I found myself adding a Set<T>
> getInstances(Class<T> baseClass) method to InjectorImpl which seems
> quite handy (I know its not hard to code, but its a useful helper
> method IMHO). I wonder if we should introduce a helper class,
> Injectors where we can add some helper methods like this so folks can
> easily look up objects using class/Matcher filters etc?
>
> If you are interested the patch is here...
> http://code.google.com/p/google-guice/issues/detail?id=62
>
> There are test cases showing the JSR 250 @PostConstruct and
> @PreDestroy working along with Spring tests showing
> InitializingBean/DisposableBean working.
>
> Any thoughts/feedback most welcome
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.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
-~----------~----~----~----~------~----~------~--~---
