[EMAIL PROTECTED] wrote:
Hello,
Ok I'm back - excuse the delayed response.
KernelConfig is good for me if it's good for you guys.
Works for me.
1. I think KernelParameters should go into a seperate package that
other packages (such as kernel) depend on. This will make it easier
when creating the bootstrap process.
Just to clarify I don't think you Leo disagreed with the package that the config class was placed into right? I thought you were just pointing out a preference for a KernelConfig object rather than the use of a general Map.
I think we agree - but I also think we are looking at the question from two perspectives. There are some issues that arrise with respect to packages shared across classloaders that can be avioded by seperation packages relative to classloader stages. This is main thing I'm focussing on at the moment. At a system level this basically comes together along the lines that Leo is talking about but at a functional level there is a desirable seperation related to the bootstrap sequence.
disagree! Recognize the tight coupling between config and component and reflect it :D
Ok I'm going to now look through leo's email regarding the use of xml instead of properties files. I like this as well but what do you think about it Steve?
XML doing primary bootstrap - NO. XML during seconday bootstrap - YES.
Should I just use both an xml configuration and a properties file representing xml path expressions in dot notation for the names of properties like so:
<foo> <bar>abc123</bar> </foo>
foo.bar=abc123
<hit the breaks/>
Now keep in mind having to have an XML parser makes the size of the jar huge and we want to minimize the footprint. Also the repo is not operational yet so we can't snarf it down. I like the idea of XML but I'm afraid we have as situation where we are feature poor while bootstraping the repo and should stick to the use of properties files while handling (a).
Primary bootstrap should be property driven - i.e. use stuff in the JDK. This lets us establish the repository after which we can load in content based on a jdk version. That content could include XML parsers etc. (if required).
Cheers, Steve.
(a) establish parameters for repository bootstrap
(b) build repository classloader
(c) boostrap repository
(d) load and bootstrap the kernel loader
Perhaps when a modern JDK with an XML parser is the de facto standard then we can go there but for now unfortunately we might have to go with property files. Thoughts?
Cheers, Alex
P.S. Just thinking out loud here.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
