One of the tests in the JMX testsuite actually shows it was wrong, but it is asserting the wrong thing. :-)

Consider the following test:

<mbean name="A" mode="ON_DEMAND"/>

<mbean name="B">

   <depends>A</depends>

</mbean>

As per the original JMX rules, that will set up two dependencies

B->A at CREATE

B->A at START

Now assume everything is at INSTALLED.

If I do B.stop() what is happening now is the uninstall of undemanded contexts will say that A is no longer required.

It correctly works out that A is still required for the CREATE dependency, and that it is no longer required for the START dependency.

So what would you expect it to do?

1) Move A back to DESCRIBE, even B needs it for the CREATE dependency

2) Move A back to CREATE which is what B demands

3) Don't do anything with A

The current answer is (1), which is obviously wrong. When A goes back to DESCRIBE, then B will also be destroyed

(because of the dependency at CREATE) which is not what I asked for.

I've got a fix that makes it do (3). i.e. while something still wants an ON_DEMAND service, it will stay in the fully INSTALLED state

(or its current state if somebody moved it).

This makes sense to me, since enabling an on demand service doesn't move it to an incompletely deployed state,

so why should undemanding do that?

I don't actually like this processing. Like I said when I originally did the ON_DEMAND processing,

you don't want to bounce your ON_DEMAND webserver just because you are redeploying your only web-app. ;-)