When I needed lifecycle support some months ago, I had implemented
this using a custom scope, which optionally wrappes the 'real' scope.
It looks like
Scope LifeCycleScope.listenFor(Scope enclosingScope,
LifeCycleListener... lifeCycleListeners);
public interface LifeCycleListener {
void postConstruct(Object instance);
void preDestroy(Object instance);
}
with postConstruct gets called right after enclosingScope.scope(key,
unscoped).get() and preDestroy when the object is not references any
more and before GC runs.
Based on this mechanism I have implemented an extension that uses
javax.annotation lifecycle annotations. As far as I see this would
fulfill your needs, would not it?
Regards, Sven
On Oct 3, 1:48 pm, "James Strachan" <[EMAIL PROTECTED]> wrote:
> 2008/10/3 [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
> > I'm intending on refactoring a lot of
> > the implementation of the InternalFactory
> > stuff in order to better support proxyless
> > circular dependencies. So if you were to
> > prepare a patch, it might not work as
> > desired.
>
> OK no worries; I'll hold off a little while.
>
> > What I am interested in is what the API
> > will look like -- how do you setup the
> > construction listeners in your module?
> > And what does the interface for handling
> > them look like?
>
> BTW I wonder should we allow the post construction listener to return
> a new instance (as it could return a proxy?) or should we restrict it
> to being able to just perform some additional injection or calling of
> lifecycle methods? The former might be more useful for optionally
> applying interceptors and returning some kinda proxy.
>
> How about something like this as a strawman API
>
> /** invoked after Guice has constructed the object T */
> public interface PostConstructionHandler<T> {
> T postConstruct(T value);
>
> }
>
> (We could pass in some kinda context as a parameter to postConstruct()
> to indicate where the value is being injected but am not sure how
> useful that really is right now)
>
> Then for example, to support Spring lifecycles we could write a class like
> this
>
> public class SpringLifecyle implements
> PostConstructionHandler<InitializingBean> {
> public InitializingBean postConstruct(InitializingBean value) {
> try {
> value.afterPropertiesSet();
> return value;
> }
> catch (Exception e) {
> throw new PostConstructionRuntimeException(e);
> }
> }
>
> }
>
> Then to register the post construction handler we can use a similar
> mechanism to the interceptor approach; so that we only cause the
> overhead of the PostConstructHandler invocations when they are
> actually used (on certain types or types with certain annotations and
> so forth).
>
> void bindPostConstructionHandler(Matcher<? super Class<?>> classMatcher,
> PostConstructionHandler<?>... handlers);
>
> Incidentally I did wonder about some kinda Module method a-la @Provides. e.g.
>
> public class SpringModule extends AbstractModule {
> ...
>
> @PostConstructHandler
> public InitializingBean postConstruct(InitializingBean value) {
> ...
> }
>
> }
>
> Though to be honest there's not gonna be that many implementations of
> PostConstructionHandler<?> around the place so I don't think we need
> to go too far in making it super easy to write them (only a few
> frameworks will implement them typically). Whats most important I
> think is avoiding their cost from most Guice users unless folks
> actually use them - so we should encourage framework folks to use a
> good Matcher to minimise PostConstructionHandler overhead.
>
> After writing this mail I'm wondering if a more natural place to add
> support for the PostConstructionHandler code is to mirror the
> Interceptor code for this rather than using the InternalFactory code.
>
> --
> James
> -------http://macstrac.blogspot.com/
>
> Open Source Integrationhttp://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
-~----------~----~----~----~------~----~------~--~---
