On Nov 30, Rickard �berg quoth:
> The basic purpose is to make sure that jboss.jcml mirrors the actual
> settings of all MBeans in the server. This means that if you add MBeans
> to jboss.conf then the initial state of those must be written to
> jboss.jcml. Similarly, if you remove MBeans from jboss.conf those must
> be removed from jboss.jcml. So, it's a synch operation mainly.
> Additionally, we will later change the configuration management so that
> changes to MBeans through a remote administration interface is persisted
> to jboss.jcml so that any such changes survive a server restart.
I know of several other systems that rewrite their own configuration to
reflect runtime changes (Unreal's dedicated server for one :-)) however
the approach that some of them take that I find particularly likable is of
merging changes to the user-writable copy with the values that were auto
saved. This way if you want to update some configuration element:
1) edit jboss.jcml
2) kill jboss
3) jboss writes state to jboss-auto.jcml
4) start jboss
5) jboss loads jboss-auto.jcml
6) jboss performs an overwrite-merge of jboss.jcml
This way you can add/edit values without having to stop the server and
edit the file while jboss is offline. As for removal of configurations,
that all depends upon whether or not jboss has a way of knowing if a
configuration stanza is being used or not. Also it depends upon how it
treats superfluous entries.
> While I understand that most people currently administer JBoss by
> directly editing jboss.jcml I do not think this will be the common
> practice in the future when the configuration and remote administration
> tools are more developed.
As someone who has spent a large amount of time administering machines in
production environments I'd just like to say that GUI and online
administration tool usage is almost entirely restricted to the
experimenting and analysis stage of evaluating a system. Once in
production manual edits of the configuration are about the only way any
changes are made. Not the least reason is that having any sort of
administrative access to a live, remote server other than an SSH session
is an untenable risk for many organizations. Another reason is that the
configuration files are checked into the revision control system (cvs
here) along side the software releases they go with.
GUI access to a production machine is more or less relegated to NT where
you need to be close enough to reboot it anyway so that the monitor and
mouse is just fine ;-).
But seriously. Other than the application itself, all of the production
machines that I have experience on/with/near have exclusively shell access
and anything that can't be administered from that mode just isn't a viable
solution. (Especially when the machines are in Singapore, Australia,
Germany and Atlanta, Georgia while you are in San Francisco.)
Now a GUI configuration file editor that can be used in absentia, *that*
would be useful. Short of that, something that at least validates syntax
is all that is really necessary as the files are first installed on
staging machines before going into production.
C=)
--------------------------------------------------------------------------
If you want to build a ship, don't drum up people together to collect wood
and don't assign them tasks and work, but rather teach them to long for
the endless immensity of the sea. -- Antoine de Saint Exupery
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// TechnoCage Inc.
--------------------------------------------------------------------------
It's not an optical illusion, it just looks like one. -- Phil White
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
