I thought about it this weekend some more, and worked on an example xml
configuration too. This is a spin off of the Jetty config, but I think most
uses will not require some of the advanced get/new stuff (which leaves you
mostly with what we have no, only more flexibly).
This is all/mostly made up at the moment...
* * *
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-server>
<jboss-server>
<!--
| set some system properties, these should really be defaults, if use
| specified on command line -Djboss.home=xxx then ${jboss.home} must
| must equal "xxx", no the value of ${jboss.boot}.
-->
<!-- jboss.boot will be set by Main, based on where run.jar was -->
<property name="jboss.home">${jboss.boot}</property>
<property name="jboss.lib">${jboss.home}/lib</property>
<property name="jboss.conf">${jboss.home}/lib</property>
<!-- these are for uses where a local file system is required -->
<property name="jboss.local">${user.home}</property>
<property name="jboss.tmp">${jboss.local}/tmp</property>
<property name="jboss.var">${jboss.local}/var</property>
<!--
| bootstrap sequencing and configuration. this contains the definitions
| of the core system services.
|
| if omitted, then a default is pulled from the resource
| default-server.xml (METAINF or org/jboss/system).
|
| domain param will default all domain'able elements to this value if
| the domain attribute is not specified. (save for services and domain tags).
-->
<bootstrap domain="JBOSS-SYSTEM">
<!--
| Setup the mbean loader, by exposing the MBeanClassLoader, we can
| have flebible control over the classes available to services from the
| same configuration. Or a classpath elem. could contain other mbean calls?
-->
<mbean name="MBeanLoader" class="org.jboss.system.MBeanLoader">
<set name="classpath">
${jboss.lib}/jboss-spine.jar,
${jboss.lib}/log4j.jar
</set>
</mbean>
<!-- Use this MBean loader for botting -->
<mbeanloader name="MBeanLoader">
<!-- get logging up and running -->
<mbean name="Logging" class="org.jboss.system.Logging">
<!-- override the default logger type for log4j -->
<set name="LoggerFactoryType">
<new class="org.jboss.log.log4j.CategoryLoggerFactory">
<!-- override the default configuration file -->
<set name="ConfigURL">${jboss.conf}/log4j.xml</set>
<!-- override the default refresh interval -->
<set name="RefreshInterval">600</set>
</new>
</set>
</mbean>
<!-- Logging is now functional -->
<!--
| next startup the library manager, with handle getting classes
|
| provides a robust mechanism for getting class libraries, may boot
| strap higher functionality after establishing link to BaseURL.
-->
<mbean name="LibraryManager"
class="org.jboss.system.LibraryManager">
<set name="BaseURL">${jboss.lib}</set>
<set name="StateDir">${jboss.var}/libcache</set>
</mbean>
<!--
| Manage security.
-->
<mbean name="SecurityManager" class="org.jboss.system.SecurityManager">
<!-- who knows -->
<set name="Password">hi</set>
</mbean>
<!--
| this is shutdown and info
|
| provides access to server lifecycle events, perhaps even a meeting place
| for system events?
-->
<mbean name="SystemManager" class="org.jboss.system.SystemManager">
<!--
| do not System.exit() when asked to shutdown, in case we are embeded,
| should still go through shutdown hooks, need to manage them in tandem
| with the runtime.
-->
<set name="ForceExit">false</set>
</mbean>
<!--
| setup the service controller and deployer
|
| this will take over with all other loading and provide a richer
| language interface.
-->
<mbean name="ServiceController"
class="org.jboss.system.ServiceController"/>
<mbean name="ServiceDeployer"
class="org.jboss.system.ServiceDeployer"/>
</mbeanloader>
<!-- if you got to here we are good, else an error will be thrown -->
</bootstrap>
<!--
| service configuration
|
| services which are not required to bootstrap, such as user services
| are defined here.
-->
<services domain="MyDefaultDomain">
<!-- use of domain element for bean grouping -->
<domain name="my.domain">
<!--
| the service element is used for mbeans that have lifecycle methods
| exposed.
-->
<service name="mybean" class="MyBeanClass">
<set name="MyAttribute">some.value</set>
</service>
</domain>
<!-- use of domain attribute -->
<service name="mybean" domain="my.other.domain" class="MyBeanClass">
<!--
| Get the service context, then modify the lifecycle map
|
| all services bound are actually wrapped in a helper object, which
| exposes a getServiceContext().
-->
<get name="ServiceContext">
<!-- provide service lifecycle method mapping overrides -->
<get name="ServiceLifecycleMap">
<!--
| set the init method to the objects prepare(), which is
| obbtained by calling ServiceLifecycleMap.getMethod(String), and
| set by calling setInit(Method).
-->
<set name="Init">
<get name="Method">prepare</get>
</set>
<!--
| disable destory calls by setting it to null, when null this
| lifecyle callback will not be invoked (the invocation goes through
| reflection).
-->
<set name="Destory"><null/></set>
<!-- the rest will remain defaults -->
</get>
</get>
<!-- back to regular JMX attribute setters -->
<set name="MyAttribute">some.value</set>
</service>
</services>
</jboss-server>
* * *
I tried to cover most usage schenarios for the xml config syntax,; I don't
expect this exact config to ever be used.
The basic concept is that Main, creates a BootLoader, passes it the URL it
has on the command line. BootLoader will download & parse the file. It
will also load/parse the resource default-server.xml, then begin to execute
the configuration, starting with properties, then checking for a
<bootloader> in the user's config. If it is not there then the version
from the defaults file will be used.
Obviously there are some details to work out, but over all I think it is
fairly sound.
Another important point is that the locations for information (libs, config
and such) are all independent system properties, which can be used together,
but can be completely independent (instead of alwayx using a base and
deriving all from it). We can provide defaults for all of these, but still
give control to the implementor.
I thought about using some xml syntax for getting a property value, but I
could not think of something that was condense enough to pallet widesread
use of it. Plus doing a subst on this is simple, though unpure.
Now, on to the Jetty-like config stuff. I think this is really, really
cool. It basically gives us super flexiblity for adapting to different
mbeans and the different was that beans get configured.
The service(s).xml stuff would probably just be the bits inside of
<services> (perhaps properties too).
The <set> stuff is basically <attribute>, but more terse (and fiting with
the other names).
<call> & <new> are nested scope elements, which operate on the returned
object. This would really make configuration of complex components much,
much easier, but allowing a configuration helper object be used or rather
plugged in. I am not sure that we need a fullblown MBean for many trivial
uses, perhaps we do...
<mbean> is just a simple managed bean, there are no service lifecycle bits
here, just load the bean. I think we should wrap the bean, then plug that
wrapper into the MBeanServer for greater flexiblity, but I don't know the
exact details of doing that.
<service> is an mbean, with lifecycle stuff, perhaps even a ServiceContext
(which is handled by the wrapper the bean is loaded inside).
<mbeanloader> probably needs some more work, but is essential a scoped
class loader, giving us greater control over the classes each service can
see (which might be needed to have 2 services using different versions of
the same library and other such magic).
This could be a simple nested <classpath> too, but this will simply hookup
the mbean creation stuff via JMX instead of hardcoding the class.
I also added a hint of support calling alternative methods for service
lifecycle stuff (so you don't have to write an adapter for this), and the
idea to expose our System.exit() usage to make it easier to embed.
So that's it (for the moment), more power, slightly more complex boot
sequence, more complex configuration where needed with out any loss of the
simplicity of the current configuration dialect.
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
