>
> I entirely agree. I was thinking more that JBoss would setup a bunch of
> SystemProperties based on the boot url like INSTALL_URL, DEPLOY_URL,
> CONF_URL etc... that MBean configurations could use.
>
> Yes, a JNDI DirContext may be nice, but how do you set one up? How do you
> map it? (I actually don't know myself, maybe it is easy? :) Seems like
> overkill when an $INSTALL_BASE_URL variable available in MBean deployment
> descriptors would be just fine.
>
The JNDI DirContext would be managed by a filesystem mbean which has an
attribute that defines the root directory of the filesystem. The notion of
abstracting
out the filesystem is really a seperate issue from the problem of
customizing a
configuration for a given host so let's drop it for this particular thread.
> An install/configuration service is a great idea, but has a few drawbacks.
> We had a funky configuration service with Orbix2000, but the problem was
> that customers had a hard time figuring out how to use it. It probably
had
> a lot to do with the complication of the design(then again, maybe not...),
> but IMHO what's simpler for JBoss than just copying the /conf, /deploy,
and
> /lib directories to a webserver and pointing run.bat to the url? IMHO it
is
> the simplest thing to setup and easiest to understand.
>
In all cases the client just points run.bat to a url and the base
configuration
is just the set of directories you are talking about. In the absence of a
target
host specific transformation the config is just copied. I'm thinking of
doing
host transformations using XSLT. The net install code would indicate which
host was requesting the installation and would look for that hosts XSL set.
The configuration administrator would specify one or more XSL
transforms that would be applied to any xml file including descriptors in
jars, wars, ears, rars, sars, etc. The advanatge of this is that we don't
need
to change the descriptor parsing code as the transform is handled
externally.
One simple XSL usage would be use a variable style references in the
original file and have the property variables replaced by their values.
> On the flip side, a configuration service can be pretty cool.....
>
> At Iona we had chained configuration domains to config the ORB. So, if my
> machine name was Bill my configuration would be something like this
>
>
> Bill : GenericConfig
> {
> install_root = "/home/bill"
> }
>
> GenericConfig
> {
> install_root = "/usr/local/"
> jetty_path = "${install_root}/jetty.xml"
> }
>
> You could "inherit" base configurations and "override" bindings to fit
your
> configuration needs. So, if my Configuration was "Bill", "jetty_path"
would
> resolve to "/home/bill/jetty.xml". Does this make sense?
>
Yes. The XSL transforms could likewise be organized into generic to specific
sets I believe.
> Hmmm...Does JNDI have this type of concept of inheriting and overriding
> bindings?
>
No. If you do a lookup on a name for an attribute there is no notion of
searching
up the tree for parent node with a binding. That behavior really is an
implementation
detail and would be easy to provide.
> What I'm really getting at is that I want to use the net-boot features of
> RabbitHole in our production application as soon as possible. The current
> existing net-boot has some problems and I thought SystemProperty
substition
> would be a quick and simple solution.
>
The notion of configuration service as a simple XSLT driven transform filter
should be easy to add and gives all of the flexibility of a system property
mechanism and more since the transforms can be context sensitive, have
simple scripting capabilities, etc. I have not made extensive use of XSLT so
maybe there are significant drawbacks that I'm not stating. This is the
solution
that I would like to try first baring some major objection.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
