> 1- we keep the jboss.conf with just the CS/XMLet start
This would allow users to replace these with their own versions? How many
users are interested in doing that? If they are they could extend from
Main, or write there own to add functionality.
> 2- or we force loading the CS from the main (always) as the front end for
> the XMLet mechanism.
This seems a like a good start to simplify the configuration of the system.
The only problem that I can see is that logging will probably not be enabled
before the CS, since users will probably want to have control over that.
> BTW, XMLet is our own JBoss extension of the default MLet mechanism,
Does XMLet provide the same functionality as MLet but is XML compliant, or
is it completely different? I remember some talk about this before, but I
never got the gist of it.
Any ways I am in favor of removing jboss.conf, or rather having on primary
file for controlling the configuration of the server. If we are still going
to use the conf/jcml style then we definitely need an XML compliant conf
parser (which is what I think XMLet does... but I am not sure).
Along the lines of loading from a URL, does this also include classes?
Such that a server install would only required the bare minimum to connect
to a server for configuration and support class/resource downloads? If that
is true, is there going to be any caching of downloaded files (for large
.jar files and such)?
I was also wondering of there might be plans to enrich the jcml dtd to
include such things as property setting, bare mbean loading (not as a
service) and perhaps the ability to use value substitution (like ant does
with ${property.name}).
Just some thoughts. I am very interested in the configuration mechanism, so
if I can help out in any way please let me know.
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
