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 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
-~----------~----~----~----~------~----~------~--~---
