In/Un callbacks should be happening at Install

[adrian.brock]

The In/Uncallbacks were setup to happen at the Configured on the thing being
registered into, this is the wrong default.

We shouldn't be installing into a registry until it has had chance to
go through its lifecycle. e.g. create() can be used to validate configuration is correct
(no missing or inconsistent properties) and fail if there is a problem.

Or the registry may need to do extra work before receiving registrations,
possibly based on the value of two parameters passed during the config stage.

I've changed the default state to be Installed (this is the "no surprises" setting).
If somebody wants it to happen earlier, then can always change it in the xml
or the annotation.

Further, there were are ZERO tests of changing whenRequired and dependentState
for the callbacks.

I created one for changing the dependentState=Instantiated
(fortunately it works :-), but this obviously needs to be tested more systematically.

[adrian.brock]

Also, related to this, it might be useful if we generalise the install
to be doable at anytime (well at least from instantiated),
rather than just when the object is "installed".

e.g.

<bean ...>
 <install bean='Registry" method="add" state="Configured">
 <parameter><this/></parameter>
 </install>
</bean>

i.e. like the incallback, you could add an object to a registry before it has
completed its lifecycle.

This is the case for example in some of the classloader stuff I'm doing
where the "Module" is added to the "ClassLoading" registry for dependency anaylsis
at "Configured" but it doesn't go through to the 'Install" (creation of the classloader)
until those dependencies are satisifed.

Currently I have to use an InstallCallback to achieve this
(which isn't a big issue except that it would only allow one ClassLoading instance).

[alesj]

Also, related to this, it might be useful if we generalise the install
to be doable at anytime (well at least from instantiated),
rather than just when the object is "installed".

Yup, I though about this once. Probably when doing callbacks, as you could also see that it's a lot similar.

Kabir's AOP callbacks also allow you to do this. Some more code is required, and pointcut must match the exact bean.
And it requires AOP. :-)

I'll push the install execution to a common Action class + add the state attribute.

[alesj]

We already have 'state' attribute, which marks the dependent state of the target bean (if there is one configured for install/uninstall).

if (install.getBean() != null)
 target = controller.getContext(install.getBean(), install.getDependentState());

What sohuld we call the new state attribute, whenRequired to make it consistent?

Should we allow this just for certain states?
I would again leave it to the user, since we don't enforce this anywhere else.

[adrian.brock]

I guess using whenRequired makes sense.

The install and incallback won't work before instantiated unless you
explicitly pass the target on the controller context when installed into the MC.
i.e. you are installing a pre-instantiated object.

For the use of should validate that there is actually something to inject?

[alesj]

For (install/) the use of (this/) should validate that there is actually something to inject?

Since we allow install execution on any InvokeDispatchContext, it boils down to the target context to inform you if it cannot invoke the method.
But I think we have pretty good info in those cases.
e.g. MBeanServer is gonna complain that the mbean is not yet registered, ReflectionUtils that the target object was null, ...

[alesj]

When the installs fail, should we just unwind from the current index?
The thing is that uninstalls are different instances, and user can order them differently than the matching installs, or install perhaps even doesn't need to have matching uninstall.
But normally they do. :-)

So, the only question is, what to do by default - execute all uninstalls or just from the failed install's index?

[adrian.brock]

"alesj" wrote:
When the installs fail, should we just unwind from the current index?
The thing is that uninstalls are different instances, and user can order them differently than the matching installs, or install perhaps even doesn't need to have matching uninstall.
But normally they do. :-)

So, the only question is, what to do by default - execute all uninstalls or just from the failed install's index?

I'd just execute all the unintalls and ignore errors.
But you only need to do that if one of the installs has suceeded.

Like you said, install/uninstall are not necessarily symmetric.

[alesj]

I'd just execute all the unintalls and ignore errors.
But you only need to do that if one of the installs has suceeded.

Like you said, install/uninstall are not necessarily symmetric.

I've still left a way for users to override the failure behavior, e.g. applying the uninstalls only from the current installs index.
But by default we do what quote suggests. ;-)