Splitting up geronimo-system

[Jeremy Boynes <jb...@apache.org>]

The original intention here was that this module would contain just the 
basics needed to get a kernel running in a VM. However, the amount of 
stuff that is needed to do that has grown and things have started to get 
specialized (for example, the stuff for handling endorsed dirs, logging, 
command line parsing, the tools jar hack, and more).

With the ability to package configurations from their own Maven module 
it makes sense to move some of this code into those modules. For 
example, the command line parsing stuff can move into the module for the 
command line tool that is actually using it; same with logging setup so 
that it can be configured appropriately for client, server or plugin 
operation.

By moving the main entry point into the executable module itself it also 
gives it a chance to do what it needs to be done before bootstrapping 
the kernel. This would allow us to eliminate some of the static 
initialization blocks of the "make sure this runs first" type which are 
a little fragile.

--
Jeremy

Re: Splitting up geronimo-system

[Jeremy Boynes <jb...@apache.org>]

Dain Sundstrom wrote:
> I'm a bit confused about what specifically you are proposing to move.  
> For example, would it be the full logging stuff or just the logging 
> initializer code?
> 

Everything that is not pertinent; system has become a junk drawer for 
"stuff that needs to happen early" and "stuff that might be done by a 
couple of configs". It's getting a bit like the common module (which 
could also use a clean out).

Take logging - the needs of a command line tool are different from those 
of a daemon (e.g. a command line tool runs and exits so you don't need 
to be able to change properties whilst it is running which simplifies 
things). But now both client and server are using the same mechanisms as 
defined in system.

> Also, are we going to loose reuse if we start moving this code to 
> configuration packaging modules?  I would assume that if we move the 
> command line stuff to one the packaged configuration, and another needed 
> the same command line code it would need to make a copy of the source code.
> 

Most of the reuse in that example comes from commons-cli - the rest is 
specific to the command being run which by its nature is not reusable. I 
  think there's quite a bit more like that.

What got me thinking about this was wanting to add command line options 
to the server (e.g. so you can pass a list of configs in a file) and 
seeing that I would be conflicting with other stuff in Daemon.

--
Jeremy

Re: Splitting up geronimo-system

[Dain Sundstrom <ds...@gluecode.com>]

I'm a bit confused about what specifically you are proposing to move.  
For example, would it be the full logging stuff or just the logging 
initializer code?

Also, are we going to loose reuse if we start moving this code to 
configuration packaging modules?  I would assume that if we move the 
command line stuff to one the packaged configuration, and another 
needed the same command line code it would need to make a copy of the 
source code.

One last thing, do we really want to be moving code and changing the 
build right now?  I like the idea, but I'm not sure about the timing.

The static initializers really do suck :)

-dain

--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26

On Mar 31, 2005, at 11:03 AM, Jeremy Boynes wrote:

> The original intention here was that this module would contain just 
> the basics needed to get a kernel running in a VM. However, the amount 
> of stuff that is needed to do that has grown and things have started 
> to get specialized (for example, the stuff for handling endorsed dirs, 
> logging, command line parsing, the tools jar hack, and more).
>
> With the ability to package configurations from their own Maven module 
> it makes sense to move some of this code into those modules. For 
> example, the command line parsing stuff can move into the module for 
> the command line tool that is actually using it; same with logging 
> setup so that it can be configured appropriately for client, server or 
> plugin operation.
>
> By moving the main entry point into the executable module itself it 
> also gives it a chance to do what it needs to be done before 
> bootstrapping the kernel. This would allow us to eliminate some of the 
> static initialization blocks of the "make sure this runs first" type 
> which are a little fragile.
>
> --
> Jeremy