-
45. Re: Scoped beans deployment
"alesj" wrote:
What about the things we already do in DescribeAction? Should be moved to this preparation stage as well?
No, because most of what is done in the DecribeAction cannot be done
until dependencies are satisifed. Most importantly classloading dependencies
when that has been integrated.
e.g. You don't want to ask AOP for the dependencies if the class is not deployed yet.
Nor do you want to try to retrieve the BeanInfo.
But, you don't need classloading dependencies satisifed to create a scope
or a scoped kernel. -
46. Re: Scoped beans deployment
"adrian@jboss.org" wrote:
But, you don't need classloading dependencies satisifed to create a scope
or a scoped kernel.
Perhaps an even safer mechanism would be to leave the context
in the NOT_YET_INSTALLED state in the root kernel until the describe action
dependencies are satisifed. Then promote it to the scoped kernel
in the describe action?
I'm thinking of the case where the class itself is annotated with the scope.
You cannot retrieve the annotation from the class until the classloading dependencies
are satisifed. -
47. Re: Scoped beans deployment
"adrian@jboss.org" wrote:
I'm thinking of the case where the class itself is annotated with the scope.
You cannot retrieve the annotation from the class until the classloading dependencies
are satisifed.
Yup, you're right.
Which Controller SPI to modify with Scoping - plain Controller or KernelController? -
48. Re: Scoped beans deployment
"adrian@jboss.org" wrote:
Perhaps an even safer mechanism would be to leave the context
in the NOT_YET_INSTALLED state in the root kernel until the describe action
dependencies are satisifed. Then promote it to the scoped kernel
in the describe action?
Sounds good, but quite un-natural.
What about adding additional state after DESCRIBE --> SCOPE? -
49. Re: Scoped beans deployment
"alesj" wrote:
Which Controller SPI to modify with Scoping - plain Controller or KernelController?
The core one, since MBeans should be allowed to have a scope as well,
or at least they should be able to define scoped metadata and be associated
with a scope.
Although I'm not sure we can support scoped MBeanServers. ;-)
We'll at least not until the cascading feature is added in JMX2.0 -
50. Re: Scoped beans deployment
"alesj" wrote:
What about adding additional state after DESCRIBE --> SCOPE?
What would that give other than having a smaller/simpler install action?
i.e. Is there is a logical difference between the two where you might want
one context in the Described state and another in the Scoped state to satisfy
some form of custom dependency? -
51. Re: Scoped beans deployment
"adrian@jboss.org" wrote:
Perhaps an even safer mechanism would be to leave the context
in the NOT_YET_INSTALLED state in the root kernel until the describe action
dependencies are satisifed. Then promote it to the scoped kernel
in the describe action?
This means 'going' to DescribeAction twice?
Or I don't see it how you are trying to do this ... -
52. Re: Scoped beans deployment
Ah ok. I sort of agree but for a different reason.
We might want people to be able to override the DescribeAction with custom actions
but they don't necessarily want to overide the scoping which will just be a
"do it' from the information in the BeanMetaData.
I think pre-install would be a better name than scope for this action/state.
i.e. It is here where we modify the context to move it to a different scope
(controller). The later actions will then see context.getController() as the correct one
according to the scope. -
53. Re: Scoped beans deployment
"adrian@jboss.org" wrote:
It is here where we modify the context to move it to a different scope
(controller). The later actions will then see context.getController() as the correct one
according to the scope.
But would this work for dependency items we add at MetaDataVisitorNode.initialVisit (when Controller is set to ControllerContext)?
Wouldn't they be tried to be resolved against parent Controller, which wouldn't know about dependency being in the right state (installed, ...)? -
54. Re: Scoped beans deployment
But isn't that something you already started to workaround with the
initial and describe visit?
i.e. The visitor is already in two stages.
It should simply be a case of making sure that the visited metadata uses
the correct controller.
In fact, the problem is where the visitee doesKernelControllerContext controllerContext = visitor.getControllerContext(); // Remember in local state controller = (KernelController) controllerContext.getController();
or similar.
Instead, it should just remember the ControllerContext and ask
for the controller from the context when it needs it.
i.e. the second line should be done lazily -
55. Re: Scoped beans deployment
"adrian@jboss.org" wrote:
But isn't that something you already started to workaround with the
initial and describe visit?
i.e. The visitor is already in two stages.
It should simply be a case of making sure that the visited metadata uses
the correct controller.
In fact, the problem is where the visitee doesKernelControllerContext controllerContext = visitor.getControllerContext(); // Remember in local state controller = (KernelController) controllerContext.getController();
or similar.
Instead, it should just remember the ControllerContext and ask
for the controller from the context when it needs it.
i.e. the second line should be done lazily
Ok, Controller should be set (lazily) in the 2nd (describe) phase - where possible (and I think it is possible in all cases).
But that is not the problem I have in mind.
e.g. When we add DependencyItem in DependsMetaData (or DependencyValueMetaData, ...), this context waits for this to be resolved till some other bean supplies this dependency - but it does this via AbstractController.resolveContexts which puts itself as a parameter to DependencyInfo.resolveDependencies. So we are 'asking' the 'describe state' Controller to resolve some bean that will actually be installed in child Controller.public boolean resolve(Controller controller) { boolean previous = resolved; ControllerContext context; if (dependentState == null) context = controller.getInstalledContext(iDependOn); else { context = controller.getContext(iDependOn, dependentState); if (context == null) { if (ControllerState.INSTALLED.equals(dependentState)) context = controller.getInstalledContext(iDependOn); } } -
56. Re: Scoped beans deployment
Yes, but a missing DESCRIBED dependency should not stop the context
moving to the new PRE_INSTALL state.
By default most dependencies are required at INSTANTIATED,
see AbstractKernelControllerContextprotected abstract class AbstractMetaDataVistor implements MetaDataVisitor, PrivilegedAction<Object> { /** * The current context for when the dependencies are required */ protected ControllerState contextState = ControllerState.INSTANTIATED;
Parts of the tree override the "whenRequired" to be later,
e.g. property injections are required at CONFIGURED.
The only problematic one I can see is the ClassLoader,
which is currently required at DESCRIBED.
This should be moved to the PRE_INSTALLED since we need the classloader
to get the class, to get the annotations. -
57. Re: Scoped beans deployment
NOTE: If you look at AbstractDependencyInfo, you'll see that it only invokes
the dependency items for the next state that it is interested in.public boolean resolveDependencies(Controller controller, ControllerState state) { boolean resolved = true; if (unresolved.isEmpty() == false) { for (Iterator i = unresolved.iterator(); i.hasNext();) { DependencyItem item = (DependencyItem) i.next(); // HERE, only try to resolve the next state, not all dependencies if (state.equals(item.getWhenRequired()) && item.resolve(controller) == false) { resolved = false; break; } } } return resolved; }
So when we ask is "PRE_INSTALL" resolved, it isn't going to look at later dependencies. -
58. Re: Scoped beans deployment
Ok, so all we need to do is to make sure that DependencyInfo for whenRequired == DESCRIBE || PRE_INSTALL doesn't require something that only gets resolved in later state - outside current Controller scope.
So this probably means that we need to limit the whenRequired attribute where we are able to specify it. I'll look if there are some issues with our current usage.
Yes, but a missing DESCRIBED dependency should not stop the context
moving to the new PRE_INSTALL state.
How do you move forward with this dependency? -
59. Re: Scoped beans deployment
"alesj" wrote:
Yes, but a missing DESCRIBED dependency should not stop the context
moving to the new PRE_INSTALL state.
How do you move forward with this dependency?
I don't understand the question?
Let me go through the state in detail and hopefully this will clarify it?
1) Somebody intalls a context that wants to be scoped.
2) This goes through the visitor which builds up the dependencies
and they internally take a reference to the ControllerContext for later use if
required.
3) We check that all "PREINSTALL" dependencies are satisfied,
basically the classloader and in future the classloading dependencies
4) We switch the context to the scoped controller (creating it if necessary)
5) We check that all "DESCRIBED" dependencies are satisfied
(since the classloader has moved to PREINSTALL this will be none by default)
6) Business as usual, except the context is now in a scoped controller.
It's ugly (the switching of the controller),
but it does allow us to be able to define PREINSTALL dependencies
like the classloading and potentially have seperate DESCRIBED dependencies
using the normal mechanisms.