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