> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> M Stark
> Sent: Monday, October 29, 2001 5:26 PM
> To: Jboss-Development@Lists. Sourceforge. Net
> Subject: Re: [JBoss-dev] Using system properties in jboss.jcml would
> help net boot
>
>
> Your making sense, but for the use cases your talking about I don't agree
> with the use of system properties. Rather, file paths should be
> relative to
> a
> "filesystem" JNDI DirContext so that both the location and implementation
> of the filesystem is abstracted out. System properties also
> require setup on
> the target host that I would rather handle on the configuration service.
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.
> My view of net installs is that I run the same command line on each
> install target host and I get a properly configured JBoss server without
> needing to locally configure the target host environment.
>
I totally agree.
> This potentially requires an ability to take a base configuration
> and apply
> a target host specific transformation. The install service would be a
> JBoss servlet instead of a static web server that would handle the target
> host transformations.
>
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.
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?
Hmmm...Does JNDI have this type of concept of inheriting and overriding
bindings?
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.
Bill
> ----- Original Message -----
> From: Bill Burke
> To: Jboss-Development@Lists. Sourceforge. Net
> Sent: Monday, October 29, 2001 10:23 AM
> Subject: [JBoss-dev] Using system properties in jboss.jcml would help net
> boot
>
>
> Hey,
>
> I think it would be nice to be able to access system properties within
> jboss.jcml or any other MBean XML descriptor. I think this would greatly
> help the net-boot(--net-install) feature of JBoss 3.0. For example, Jetty
> is packaged in a .sar in JBoss 3.0. In that sar is the MBean XML
> descriptor
> that has a hardcoded path to Jetty's configuration file
> 'jetty.xml'. Since
> it is hardcoded this sar file cannot be deployed from a net
> installation of
> jboss. Instead of putting the url "../conf/default/jetty.xml" as the path
> to jetty's configuration, I think something like
> "${INSTALL_PATH}/conf/${CONFIG_DIR}/jetty.xml" would make things more
> flexible. JBoss would set up the INSTALL_PATH and CONFIG_DIR on
> startup as
> System Properties. Am I making any sense?
>
> Bill
>
>
> _______________________________________________
> 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
