Hi,
I'm trying really hard to understand what kind of variability you are going
for here and failing totally. When would you not want to start logging,
info, shutdown, and the xml-based mbean loading/classloading/starting
framework first and in that order? Can you give a concrete scenario?
Among the command line parameters, I see a use in the libDir to indicate
where the log4j and initial mbean classes (jboss-spine.jar) are, and the
url of the configuration. I don't see much use in patch or installation
directory. The configuration would either be a .sar including all needed
classes or an *-service.xml with a classpath referencing all classes.
I'm not very clear about exactly what needs to be on a local machine when
you start jboss. I think the Main class ;-)... and it looks like the
jmxri.jar to get the mbean server going... what else? Do we want to try to
minimize this? Download the jmxri (or replacement)?
I'm mostly really curios about what situation you would want to start the
pre-jboss-service.xml stuff in a different order or with different
components -- or did I completely miss what you are talking about?
Thanks
david jencks
On 2001.09.07 20:56:51 -0400 Jason Dillon wrote:
> I understand that the jboss.conf or boot.xml stuff was just complicating
> things, though hard coding isn't the right solution. That said, I don't
> really have a good solution at the moment, though I do have some ideas
> (of
> course).
>
> > configurability is good when it is needed, in this case it is not
> (imho,
> > feel free to flame). Therefore "simple is the word...."
>
> I certainly don't want to complicate, but I think we can find a simple
> solution that provides excellent configurability for most (if not all)
> applications.
>
> We don't want to over simplify our systems and force user installs to be
> complicated to work around the rigidity of the boot system.
>
> * * *
>
> Let us simplify Main even more. All it really needs todo is pull down a
> url, parse it then load the core components.
>
> As I mentioned before, lets drop the config name stuff and let the url
> handle that for us:
>
> http://configserver/default
>
> or
>
> http://configserver/some-other-config
>
> We can still keep the patch stuff around, which would work the same.
>
> At this point, we download the content of the url, which is expected to
> be
> the boot loader .xml. The responsiblity of this is to setup the boot
> classpath, then logging and then the support services for loading the
> rest of the system.
>
> It could be that this boot.xml is really the jboss-system.xml or whatever
> the main config file is called, it contains some extra elements
> describing
> the boot strapping sequence (and config options too it). If it does not
> exist then we can pull a boot.xml from resource and use it as the seed,
> then
> contiure parsing the file as normal.
>
> I don't think that users would object to having one config file, which
> listed 6 special services. It is having two files, of which one is not
> even
> really an xml file, which caused confusion.
>
> We could even add some app level <include> support which would allow us
> to
> pull configs from other urls or from system resources.
>
> This needs some more work before I would even consider moving twords it,
> but
> I think that this is a positive direction to take this part of the
> system.
>
> The goals being:
>
> 1) hook up real logging as soon as possible
>
> 2) make the boot sequence configurable
>
> 3) make the configuration selection simple
>
> --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
