DeployerMBeanSupport to restrictive

[maddisondavid]

In DeployerMBeanSupport::deploy(String url) it checks to see if the URL has been deployed, if it has, it stops the re-deployment, stating it's already deployed.

When creating a new deployer based on DeployerMBeanSupport, I find this to restrictive. It would be cool, and less work for me, if it could automatically call undeploy(url, info), rather than stop the deployment. After all, it must be a re-deployment for some reason, because otherwise the autodeployer wouldn't have called it!

[adrian.brock]

Hi,

I've been looking at adding a method
redeploy(URL) to DeployerMBeanSupport.

The default implementation would be as now,
but each deployer could change the behaviour.

Potentially, the redeploy() could handshake the old
deployment with the new one avoiding any loss of
service.

I haven't got very far with it. I couldn't work out
where the responsibilties lie between the AutoDeployer and the Deployer, my implementation got confused with the different behaviour of J2eeDeployer and DeployerMBeanSupport.
I don't think the required behaviour is defined.

It would be nice to be able to fix the AutoDeployer, get the old AutoDeployer to deploy the new one and hand its url watches over.

Of course there is a problem with the JMX registration, I haven't figured that one out yet!

Regards,
Adrian

[adrian.brock]

And of course,

your deployer can just do

void redeploy(URL u)
{
undeploy(u);
deploy(u);
}

Regards,
Adrian

[maddisondavid]

but DeployerMBeanSupport-Deploy(String) is called by the AutoDeployer, and as such you cann't get in before it. If a deployment is already registered and the AutoDeployer, calls deploy then the deployer should unregister the current deployment and do a re-deploy. I don't think there's a need for a redeploy method.

It appears that DeployerMBeanSupport was built for the service deployer.

[adrian.brock]

Hi,

I was thinking of making it more like JNDI and rebind.
Just like JNDI you can't use bind when something is already bound to that name.

If the AutoDeployer knows it is already deployed it can invoke redeploy to allow the deployer to optimize the redeployment.

Alternatively, DeployerMBeanSupport could redeploy by default.
If the deployer doesn't like redeploy it can always raise an exception or warning.

Regards,
Adrian

[davidjencks]

IM not very humble opinion autodeployer needs to undeploy and redeploy when it detects a timestamp change. Putting the responsibility elsewhere would be a large error IMO. I've been planning this change for a couple of months but keep getting sidetracked. If anyone else wants to take a look be my guest.

[adrian.brock]

Hi,

undeploy();
deploy();

seems to work for both the ServiceDeployer and the RARDeployer,
both derived from DeployerMBeanSupport

at least from my testing

seems => I haven't run the testsuite over it,
but then I never managed to get the testuite to not hang(deadlock??) the few times I've tried to run it :-(

I'll post it to the dev-list see, if anybody has a good reason for this not being the behaviour.

Regards,
Adrian

[adrian.brock]

Not much response from the dev-list,
but then it is a Sunday. In fact only David.

So its 3 votes to nil for doing
undeploy()
deploy()
in the AutoDeployer

I'm still a bit concerned about Auto-redeploying
services and getting suspensions.
But maybe that's just something that Sys-admins should
be aware of.

Regards,
Adrian

[davidjencks]

> I'm still a bit concerned about Auto-redeploying
> services and getting suspensions.

What specifically are your concerns? Everything that stopped as a consequence of an undeploy should start again as a consequence of the [re]deploy. Marc may be removing the dependency management based on the service.xml classpath element, but mbean-ref dependencies I think (and hope) he is keeping. I figured that if you changed a file, you meant it, and all the dependencies should be taken care of, so for instance if you changed an mbean class and redeployed the jar containing it all the mbeans of that class should be undeployed and redeployed automatically when the new class becomes available. It's not quite this nice at the moment with classes, there's just classpath declarations of dependencies, but undeploy and auto-redeploy seem to work ok. (Marc has been working on this code, and I don't know what his plans are. This is how it works in cvs today.)

[adrian.brock]

Hi,

My only concern was accidentially changing a service.
It's probably best if we don't try to cater for
accidents :-)

Regards,
Adrian