A better approach would be for your MBean to lookup the AutoDeployer in the MBeanServer and add yourself through setDeployers(String) during your preRegister.
But, setDeployers only works when the AutoDeployer hasn't already started.
A new method addDeployer(ObjectName) is probably better.
A removeDeployer(ObjectName) would keep things tidy.
This could all be hidden from you in
I think this would generalise to all the other deployers except ServiceDeployer.
I'll have a go at implementing this evening to see what problems it causes.
I know ServiceDeployer is the only deployer derived from DeployerMBeanSupport at the moment.
My orginal idea was to make DeployerMBeanSupport do the work of registering the Deployer, (in fact this is how I thought it worked until I did some digging). However I've used, (probably not wise), DeployerMBeanSupport in other MBeans, that need the services it provides. These MBeans aren't actuall deployers, they deploy their internal services, (such as .WAR's), on service start. Your idea would still work, as these MBeans have accept=false on the Filter.
> My orginal idea was to make DeployerMBeanSupport do
> the work of registering the Deployer, (in fact this
> is how I thought it worked until I did some digging).
> However I've used, (probably not wise),
I think I agree here, make the deployer lookup the AutoDeployer and register with it.
In fact I would hardcode the MBean name of the autodeployer in the deployermbeansupport and overwrite only if the child deployer overwrites that name.
I agree with your original assesment that putting the names of the deployers in the autodeployer is a braindead idea, fix it. Good call
A while back I tinkered with something I called a ServiceRegistarMBean (because I was dissatisfied with the jmx relationship service).
Basically it had
void registerAs(ObjectName mb, String role)
ObjectName getRoleMBeans(String role)
and a notification broadcaster/listener bit that escapes me now...
The final bit was a tag in my xml config which was
If the "with" value was not supplied then it would default to the current deployer/service_manager.
The idea was that there was no implicit notion of an mbean being *anything* apart from something that was registered with the server, had attributes set, and optionally registered with a registrar. So, if you wanted your mbean to be treated as a service you'd need to say to make sure your mbean would get start/stop called.
I did it mainly to support nested deployers so I could say and have my nested deployer have its deploy() method called before any start()/stop() nonsense (directly in response to the registerAs call).
In the end it was more complex than I needed so I purged it ;-P
Perhaps something similar in jboss might help here and in the other cases that caused init/destroy to be resurrected?
I've submitted a patch for this that works.
The diffs are based on Sunday's snapshot 2001/12/09.
There's some untidyness problems mainly to do with the names of the methods and logging at startup/shutdown
I've also noted some existing problems with the
current AutoDeployer/Deployers responsibilties.