Deploying Deployers

[maddisondavid]

I'm currently working on the JBoss.NET project, and as you'd expect we have a DeployerMBean in order to hot deploy web services, (very cool!).

Anyway my problem is that deployer MBeans have to be known to the AutoDeployer BEFORE the system starts, that is it only recognises the DeployerMBean if it's ObjectName has been set in jboss-service.xml. This breaks the 'Dropin' emphasis of third part modules.

My idea which would provide a fix is: Add an IsDeployer attribute to the MBean node. The ServiceCreator see this attribute and registers the name with the AutoDeployer, (through a new method). Then when the MBean is created, and the AutoDeployer notified, it has the MBean registered as a deployer, and does the appropriate business.

[adrian.brock]

Hi,

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
DeployerMBeanSupport.preRegister and
DeployerMBeanSupport.postUnregister

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.

Regards,
Adrian

[maddisondavid]

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.

[marc.fleury]

> 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

[squirest]

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

for example.

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?

Trev

[adrian.brock]

David,

I've submitted a patch for this that works.

http://sourceforge.net/tracker/index.php?func=detail&aid=491497&group_id=22866&atid=376687

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.

Regards,
Adrian