Jason,
I'm still confused about what you are trying to accomplish here. I would
really appreciate it if you could take a few minutes and write down,
without specifying a notation, the sequence of events you are trying to
control and the variation points along that sequence.
for instance (made up quickly),
Admin logs into server#57 with ssh. Server#57 has jboss-spine.jar on it.
Admin starts jboss using run.sh
--variation points: location of log4j config, location of
jboss-service.xml, location of deploy/lib, may be starting an app that has
jboss embedded.
jboss spine starts up
starts log4j
starts MBeanClassLoader
starts info
starts shutdown
starts ServiceController
starts ServiceDeployer
processes jboss-service.xml
autodeploys sar and *-service.xml packages from deploy/lib
--variation points: shutdown not necessary if started embedded.
...
If you could do this I would find it _much_ easier to think about how to
implement the functionality.
thanks
david jencks
On 2001.09.10 04:44:54 -0400 Jason Dillon wrote:
> 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
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
