Good point. We could also add more callback methods to the listener...
interface InjectableTypeListener {
void inject(...);
void afterInjection(...);
}
Bob
On Wed, Apr 1, 2009 at 11:49 AM, James Strachan <[email protected]>wrote:
>
> When using optional injection points other than just a constructor,
> there's sometimes a need for a @PostConstruct callback (if nothing
> else to implement JSR250/EJB3 :). e.g.
>
> public class Cheese {
> @Inject Foo foo;
> @Resource bar;
> @PersistentContext context;
>
> ...
> @PostConstruct
> public void check() {
> // all injection completed here so lets setup some things or validate
> }
> }
>
> currently different parts of different Modules could register
> different InjectionListener implementations to process, say,
> @Resource, @PersistentContext, @PostConstruct.
>
> e.g. we might have a JSR 250 module and an EJB/JPA module which are
> optional but folks could use them together if they wanted JSR 250 and
> EJB.
>
> The tricky bit is - @PostConstruct is a kinda special kind of
> InjectionListener as it wants to go last after all the mutation has
> completed. Currently it looks like the order is determined by the
> registration order in the module right?
>
> I wonder if there's a way to somehow denote a special kind of
> InjectionListener as going last - after all the mutation listeners? So
> a kind of post initialisation listener.
>
> This isn't required for *just* JSR 250; but I'm thinking a little
> ahead here - if there's a spring annotations module, an EJB3/JPA
> module and a JSR 250 module - it could be slightly tricky ensuring
> that the listeners are all added in the correct order.
>
>
> One really simple idea is maybe the Encounter could have a method
> registerPostInject(listener) which just adds the listener to separate
> list to the listeners list; which is then appended to the other list
> when all of the modules have been initialised? i.e. so the encounter
> still passes a single list of listeners to its callers (e.g.
> ConstructorInjector) - but that there's a concrete way to specify
> listeners that are fired after all the other injection listeners are
> fired.
>
> It'd be a pretty minor change; as the Encounter object is shared
> across all invocations of the injectable type listeners; it'd just be
> a way for any 'post commit hooks' to be processed after the other
> kinds of listener (which typically inject/mutate the object).
>
> i.e. so it just adds one method to Encounter and adds one extra
> (optional & lazy) list object there.
>
> Thoughts?
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---
