-
15. Re: Lifecycle aspects revisited
I'm saying we should be able to intercept other contexts events,
e.g. JMX events which isn't a KernelControllerContext it is a ServiceControllerContext.
Look at the interface I mentioned. -
16. Re: Lifecycle aspects revisited
At the moment the lifecycle callbacks are driven by KernelControllerContextAction. I could move this into the AbstractControllerContext.install() and uninstall() methods. That should make it available to all types of contexts? Assuming that they extend AbstractControllerContext of course.
The main problem with this is that the lifecycle metadata stuff lives in BeanMetaData which is in the kernel project and so is not visible from the AbstractControllerContext. If I have understood you correctly, this would then need to be moved out or changed into something else that is usable by AbstractControllerContext? -
17. Re: Lifecycle aspects revisited
"kabir.khan@jboss.com" wrote:
At the moment the lifecycle callbacks are driven by KernelControllerContextAction. I could move this into the AbstractControllerContext.install() and uninstall() methods. That should make it available to all types of contexts? Assuming that they extend AbstractControllerContext of course.
The main problem with this is that the lifecycle metadata stuff lives in BeanMetaData which is in the kernel project and so is not visible from the AbstractControllerContext. If I have understood you correctly, this would then need to be moved out or changed into something else that is usable by AbstractControllerContext?
Does silence mean approval in this case? -
18. Re: Lifecycle aspects revisited
"kabir.khan@jboss.com" wrote:
Does silence mean approval in this case?
Every context should (optionally) have an associated scope/metadata.
You are correct, this is only currently implemented for POJO, but it should change,
see the discussion on scoped kernels. -
19. Re: Lifecycle aspects revisited
You are talking about the metadata repository right? From what I gather it seem you want this as the "holder" for the callbacks?
I am unclear as to whether you think I should make the callers of this chain into somewhere visible for the dependency project and have that (AbstractControllerContext) or have the individual implementations of ControllerContextAction (as what I have done in KernelControllerContextAction)? -
20. Re: Lifecycle aspects revisited
I'll rephrase in English :-)
I am unclear as to whether you think I should move the information about the callbacks (currently LifecycleMetaData) somewhere visible from the dependency project and have AbstractControllerContext invoke them, or have the individual implementations of ControllerContextAction (as what I have done in KernelControllerContextAction) invoke these? -
21. Re: Lifecycle aspects revisited
That's the same question that Ales has. :-)
In practice, only AbstractControllerContext defines a per state callback.
MC -> AbstractControllerContext -> ControllerContextAction
The default implementation is to callback on the ControllerContext,
i.e. the last step is necessarily going to happen if the context implementation
does not extend AbstractControllerContext.
I'm arguing that the lifecycle callbacks should apply to at least all
AbstractControllerContext implementations, not just POJO.
Ales thinks that ControllerContextAction should be part of the API so it would
apply everywhere? -
22. Re: Lifecycle aspects revisited
"adrian@jboss.org" wrote:
The default implementation is to callback on the ControllerContext,
i.e. the last step is necessarily going to happen if the context implementation
does not extend AbstractControllerContext.
You mean if a ControllerContext impl does NOT extend AbstractControllerContext then we miss out on the callbacks."adrian@jboss.org" wrote:
I'm arguing that the lifecycle callbacks should apply to at least all
AbstractControllerContext implementations, not just POJO.
I agree and understand that"adrian@jboss.org" wrote:
Ales thinks that ControllerContextAction should be part of the API so it would
apply everywhere?
Whereever it goes I think it will be a trivial change, so I will wait for you two to figure out whether it is part of the API or not. In any case the "lifecycle information holder" (currently LifecycleBeanMetaData) will need renaming/moving into something visble from the dependency project. -
-
24. Re: Lifecycle aspects revisited
"kabir.khan@jboss.com" wrote:
Whereever it goes I think it will be a trivial change, so I will wait for you two to figure out whether it is part of the API or not. In any case the "lifecycle information holder" (currently LifecycleBeanMetaData) will need renaming/moving into something visble from the dependency project.
Maybe ControllerContextAction's place is really plugins, but at least its .spi. package should be renamed.
We could introduce new CallbackControllerContextAction (extends ControllerContextAction) which would define the API behind your callbacks.