Yeah - either works for me. I would say post injection hooks are very rare. I can currently only think of 2 possible implementations (@PostConstruct and supporting Spring' InitializingBean). Also they tend to be mutually exclusive to any particular injection annotation - eg @PostConstruct could be used with @Resource, @PersistentContext or @Autowired (from spring). So pretty much all InjectionListener implementations i can imagine would only implement one of the methods.
Also i think the former might be a little bit more efficient; trading a new List lazily created which is appended to the other at class inspection time versus avoiding a double iterate & invocation of lots of empty methods (though hotspot would no doubt speed that up to e barely noticable :-). Don't mind though. Do you want a patch? On 01/04/2009, Bob Lee <[email protected]> wrote: > 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/ >> >> > >> > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
