Have you considered using the AopAlliance ConstructorInterceptors as the
interface? This will match nicely with the MethodInterceptors.
Dhanji.
On Fri, Oct 3, 2008 at 9: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 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
-~----------~----~----~----~------~----~------~--~---
