#119 New mbean dependency mech: mq changes

[David Jencks]

I've rewritten the mbean dependency support in jboss 3
to rely on direct mbean - mbean dependencies instead of
the depends tag in *-service.xml files: this tag has
been eliminated.

There are two new elements inside mbean in *service.xml
files:

<mbean-ref name="(property name)">(object name)</mbean-ref>

and

<mbean-ref-list name="(property name)">
<mbean-ref-list-element>(object
name)</mbean-ref-list-element>
...(repeated)
</mbean-ref-list>

It is expected that the mbean has an ObjectName -
valued property (mbean-ref) or Collection valued
property (mbean-ref-list): on configuration these
properties are set to the supplied ObjectName. The
mbean is started only when all the referred-to mbeans
have been started, and is stopped whenever one of the
referred-to mbeans is stopped.

ConnectionFactoryLoaders have been modified to take
advantage of this system. A RarDeployment mbean has
been introduced to display the properties of the
deployed rar and to be depended on. A
ConnectionFactoryLoader has an mbean-ref to the rar it
uses: therefore it will be started only when the rar
has been successfully deployed., and stopped when the
rar is undeployed. This replaces the artificial
dependence on the RARDeployer and the mbean
notifications from RARDeployer to ConnectionFactoryLoader.

A possible future enhancement would be to allow
"property-less" dependencies of the form
<mbean-ref>(object name)</mbean-ref>
This would be useful for example to make DefaultDS
depend on hsqldb starting. There is no natural mbean
reference here, but there is a functional dependency.

Another effect of this change is that the init and
start, and stop and destroy, lifecycle events are now
executed together for each mbean. Therefore there is
no reason to keep 4, start and stop will be sufficient.
Some progress has been made to combine these methods.
In the future, ServiceMBean should only support start
and stop.

As a result of condensation of lifecylce methods,
modifications to jbossmq were necessary for proper
initialization of queues and topics on restart. This
required refactoring and rearranging the
PersistenceManager startup sequence, the StateManager
startup sequence, and the JMSQueue and JMSTopic startup
sequence. Mbean dependencies were introduced in many
places to make dependencies explicit. However, there
is still use of static JMSServer.getInstance() methods
from IL code: this makes running and testing several
PersistenceManagers simultaneously impractical.

The Logging PersistenceManager was removed as it
appears to be obsolete. In the course of this work it
appeared that the UIL code does not (before or after
the changes) pass the test suite, and that the JDBC
PersistenceManager does NOT implement recovery from
failure within a transaction, and does not pass most of
the test suite. It was possible to modify the test
suite to test all IL's (except in-vm), however due to
the static methods on JMSServer it is considerably more
difficult to test all PersistenceManagers.

The JDBC PersistenceManager was modified to work by
default with Hypersonic (or other databases supporting
java_object rather than blob). There is a flag to set
to return it to using blobs. It also creates the
tables it needs if they are not present.