Okay, I admit, I wanted to squeeze Minerva into the BETA-PROD
release.  There's now a simple xml file "jboss.dependencies" in the conf
directory.  It should be pretty self-explanitory - add a tag for the
service you want to make dependent, and then within that add tags for all
the services it depends on.
        The only trick here is that we want to treat all instances of a
service together - so it keys off the phrase "service=XXX" in the full
ObjectName of an MBean.  For example, a ClassPathExtension may have the
name ":service=ClassPathExtension,url=../../tmp/", but for purposes of
dependencies, it's service name is "ClassPathExtension" because you see
"service=ClassPathExtension" in there (delimited by comma and semicolon).
        Now, there's also a flag "required" which is itself required for
each dependency.  If that flag is set to true, the service will not load
unless the service it depends on is loaded (this is most common).  If set
to false, that indicates that we should *try* to load the service it
depends on first, but if it fails or is not available that will not
prevent the main service from being loaded.  This is the case, for
example, for "AutoDeployer depends on XADataSource" since there may or may
not be XADataSources configured, but if they are they should be loaded
first.

        And, to add the rest of my miscellaneous comments:

 - This only works for services with "service=XXX" in the name, not all
arbitrary MBeans.  Sue me.
 - I had to move xml.jar from lib/ext to lib since I parse the XML before
I initialize the services.  It would be possible to load the dependency
manager as an MBean itself, ala the Configuration service, but I don't see
what that would gain you, since this is used to start the server.  This
also means a couple extra classes in run.jar.
 - You should not need to alter the jboss.dependencies unless I left
something out (I couldn't decide whether EJBs or Tomcat should be loaded
first) or you add an MBean - you can add and remove instances of data
sources and the like freely, since the service name is the same.
 - I didn't do anything with the dependencies after startup.  In fact, the
dependency manager flushes the list after it runs.  It would make sense to
use that information for the shutdown sequence and potentially creating
JMX relations and whatnot at runtime, but that's an RFE.
 - There's now a Minerva pool for the Hypersonic database in the default
configuration.  Currently, the test beans still use the old one (which I
didn't remove).  We should change the data source in the test beans from
"Hypersonic" to "xa.Hypersonic", at which time we can remove the
DataSourceImpl entry from jboss.conf.  Any volunteers?

Aaron

P.S. You may need to "build clean"...


Reply via email to