On Mar 20, 2007, at 4:42 AM, Gianny Damour wrote:
In the meantime... can anyone tell me why we are booting up a
kernel before cli parsing? From what has congealed in my head so
far... this is for access to the repository for classloading of
bootstrap classes. Is there any other reason why we boot a kernel
here before cli parsing?
A kernel is booted before cli parsing so that classes parsing cli
arguments do not need to be defined by the system classloader.
Verbose level switches must be done prior to boot a Geronimo kernel
as they control the default log level and this initialization must
occur prior to acquire the first log instance.
The bootstrap is simple as: load a boot configuration; get a Main
implementation from it (or configurations restored when the boot
configuration is loaded); and invoke execute(String args[]) on it.
AFAIK, all the clis use this unified approach.
So do we end up with 2 kernels after everything is booted? One for
bootstrap and one for the real deal?
Why is it "a wee bit more difficult" to add commons-cli now?
Its just that cli processing is now scattered between a few classes
over 2 modules at least for Daemon. There are also a bunch more
classes, some with main() others w/o main()... which has me
scratching my head to what this is actually doing.
I'm also wondering what's the difference between Daemon and
EmbeddedDaemon?
What happens when users want to use a different repository location?
I basically understand what is going on... but I think the order of
how its being done is a odd. Like if you run:
java -jar bin/server.jar --help
You have to wait several seconds for the bootstrap kernel to load...
just to display the cli usage... that seems wrong IMO. I would
rather have commons-cli.jar and a tiny geronimo-cli.jar on the system
classpath (along with the kernels requirements), process command-line
options, then boot up the kernel and delegate to a bootstrapping Main
to finish the job.
--jason
