> > 1) Expose as much configuration to integrators as possible, with out
> > complicating the system for users who do not need to muck with the
> > boot config.
>
> Right now with rh, you can specify all the directories you need (and some
> you probably don't) as urls on the command line (as I understand what is
> happening). What specific aspects of the boot configuration do you want to
> change other than this?
This is just not true. RH/Main will take one URL and a patch directory,
then generate the other locations from the URL and setup jboss.home based on
where run.jar lives.
We are expecting configuration files to be under the given url/conf/config,
which is unneeded.
> > 2) Setup logging as soon as possible.
> This is obviously a good idea, I'm not sure how much sooner it can get if
> its run through an mbean and loaded with a recyclable classloader.
We already setup logging really soon, but we don't expose the configuration
of the logging service... which is bad.
> > I do not expect most users/integrators to change the sequence, but I do
> > expect that they might want to tweak some parameters.
> >
> > What I suggest will provide a definitive configuration file for the
> > server,
> > not just the service which are running inside.
>
> I remain less than convinced that it is a good idea to put startup
> configuration info (where the directories are, mostly, as I understand it)
> and mbean configuration info in the same file. If the current *service.xml
> format is maintained, it is possible to compose more and more large-scale
> configuration sets out of different sized chunks. If you put other
> configuration info in one of these, that one cannot be used as a chunk-- it
> is forced to be top level.
What? I am talking about the configuration file for booting the server.
This does not fall over into service.xml files at all. I want to control
how JBoss boots with out having to write/maintain my own version of Main or
a custom boot system.
The current system makes many assumptions about how the configuration of the
system will be laid out, which is not a good idea.
I am talking about exposing this configuration, for users who need it,
allowing it to be omitted (by using defaults) for those who don't.
> > I personally have not made use of the JBoss distribution layout, ever.
> > It
> > has never fit in with my deployment scheme.
>
> Is this still so true with the new web-deploy stuff from marc?
Even more so. The current system that I use must be scrapped to make use of
the new stuff. Which might be a good idea any ways, but if I do that I don't
want to be forced to use the conf/<configname>/... semantics. I would
rather specify a URL with ?params which would be served up by a JSP.
> I spent a few weeks writing
> > a
> > jython/ant based system which handles setting up the environment that
> > JBoss
> > expects from my layout. I have heard others with the same problem,
> > trying
> > to get it read files from somewhere other than conf/xxx/** and the like.
> >
> > There is no reason why we need to be strict when it comes to where these
> > files live, or how users tell JBoss where to find them.
>
> Allowing any location is good, and I think implemented. What advantage
> does an xml file have over the command line for describing location?
This is not implemented... why do you think it is?
The command line is used to provide the initial URL and property overrides,
everything else is configured via the xml config file.
Currently, to use a set of configs you need to:
./run.sh --net-install http://configserver --configuration myconfig
What I suggest is that we replace this with:
./run.sh http://configserver/myconfig
or
./run.sh http://configserver?config=myconfig
or any other way you choose to implement the JSP/Servlet which serves up the
config.
If you need to specify other bits then you can use -Djboss.* to set more
properties.
By doing this it means that we need to provide a single file (xml) which
tells the boot system what todo. I would like to figure out a way to make
the jboss-service.xml and this config live in the same file, so that we can
simplify configuration.
> Hope this isn't nitpicking or too many questions-- I really want to
> understand what you have in mind.
I really want you to understand too, so let me know how I can make it
clearer.
JBoss is a really powerful platform for running applications, lets make it
even more powerful by exposing the boot/configuration logic to allow
integrator's to adapt it to any environment.
We certainly can not foresee all of the uses of JBoss, but we can plan for
some unexpected use by exposing extra configuration.
Marc removed the boot.conf stuff to simplify the configuration and startup
logic. I think that the previous boot stuff was confusing, but it was
flexible and allowed me get up and running quickly with the layout which I
am used to.
I want to keep this simple, but not so simple that it limits how people can
use it. Simple may be the word, but flexible is the key.
The point that I am trying to make is that we can build a flexible system
that is simple in nature by exposing this configuration. The problem is how
does it all fit together, which is why I put together an example xml
snippet.
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
