Bootstrapping the Microcontainer/JBoss
I've been thinking about the bootstrap of the Microcontainer
and how it would relate to different usecases.
I can't really decide what is the best way to do it, so I want
some other thoughts on the subject. Apologies in advance
for the length of this post.
What we have now
Currently there is a KernelConfig interface that has methods like
KernelConfigurator createKernelConfigurator() throws Throwable;
This allows different implementations to decide how to construct these objects,
the default being to use system properties
KernelConfig config = new PropertyKernelConfig(System.getProperties())
This works pretty well in that you can change just about anything about the implementation. Which is important for both people wanting to use their
own implementations and providing alternate implementations for bug fixes.
It also means you can decide not to use System properties and use something else as the source of implementation configuration.
Where it doesn't work well is wanting to add new features in a unified way.
e.g. AOP, MBeanServer, MetaDataRepository, Profile Service, etc.
Alternatives
I see three options, the last one is what I prefer, but it does introduce
some extra complications.
1) Leave it as it is and just add extra methods to the Config object
2) Make a more generic config object like
Object createPlugin(String name) throws Throwable;
3) Keep the bootstrap config to a minimum and instead have a
jboss-bootstrap.xml file that defines what services you want to bootstrap.
e.g.
<bean name="AspectManager" .../> <bean name="MBeanServer" .../> etc.
There are a number of disadvantages (or complications) to this approach
but I don't think they are unsolvable.
a) A hardwired name for the jboss-bootstrap.xml file will
likely leak into other scopes that want to initiate their own kernel.
b) The late construction of some objects means we will need to
retrofit earlier objects as dependencies are satisifed.
e.g. When the MBeanServer uses AOP advices it will need the aspect
manager in place to define the advice stack, but then we need
to retrofit the AspectManager to expose it via JMX once we have
the MBeanServer.
e.g.2. The more subtle but essentially the same problem of applying
SecurityDomain protection to the SecurityManager service.
c) With the profile service in place what we really want is to
bootstrap the profile service only and then let it define these
services in the profile. e.g. This profile has AOP and JMX
d) The use of a bootstrap xml file is not very good for being able to
do something like:
./run.sh --features=aop,jmx
which is effectively also something we want to be able to do
when bootstrapping the Microcontainer in tests
So maybe rather having a single jboss-bootstrap.xml
there would be a pattern that loads jboss-bootstrap-aop.xml
when the feature is enabled.
However, with the features separated and standalone
the issue then becomes making the retrofitting work
in the case when other features are/aren't enabled.
e.g. Don't try expose the AspectManager via JMX when there is no
MBeanServer, but do expose it when the MBeanServer appears later.
