I'd like to see substitution variables in jboss.jcml so that you can use
environment variables to get at some of the hardcoded paths that need to be
set up in config
BIll
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David
> Jencks
> Sent: Monday, September 10, 2001 7:10 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] exposing boot sequence & richer xml config
>
>
> Thanks jason, now I have more questions ;-)
>
> On 2001.09.10 18:00:53 -0400 Jason Dillon wrote:
> > > I'm still confused about what you are trying to accomplish here. I
> > would
> > > really appreciate it if you could take a few minutes and write down,
> > > without specifying a notation, the sequence of events you are
> trying to
> > > control and the variation points along that sequence.
> >
> > Sure. There are three major reason why I am moving in this direction.
> >
> > 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?
> >
> > 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.
>
> >
> > 3) Provide a richer configuration lanugage.
> This seems like a very separate question to me. I've seen some discussion
> about being able to call arbitrary mbean methods during the startup
> sequence, but haven't seen a convincing example of why setting properties,
> calling init, and calling start isn't sufficient. Given a 3rd party mbean
> I would think one could wrap it in a jboss service mbean where
> the init and
> start methods called the appropriate 3rd party methods. I'm,
> well, nervous
> about making it easy to call arbitrary mbean methods on startup. Is there
> an actual example of this being required?
>
> >
> > 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.
> >
> > 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?
>
> 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?
>
>
> Hope this isn't nitpicking or too many questions-- I really want to
> understand what you have in mind.
>
> thanks
> david jencks
> >
> > Does that help, or have I just clouded the issue more?
> >
> > --jason
> >
> >
> > _______________________________________________
> > 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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
