Re: Any plans on Validator?

[Jeremy Boynes]

Aaron Mulder wrote:
	I think it needs to happen during distribution, before we attempt 
to start the module.  However, this depends on the ClassSpace being set 
up, because the validator will want to load classes to make sure the right 
methods are present, etc.

I've been thinking that we need a change to the way deployment works 
here that would fit in with that - see a prior post on the deployment 
problem.

Current thought is to introduce a couple of new subsystems:
1) a component repository which is used as the source of components
   for example, we could publish service's here or a user could
   publish their archives. This is similar to the repository used in
   maven and would integrate with ruper as well
2) a config store, where we place runtime configurations
   this is always local to the instance and comprises two things:
   a) a set of locations that are entries in the classpath
      e.g. a ejb-jar or an expanded war
   b) a persisted form of the GBeans that comprise the runtime state
      this could be serialized objects (yuk) or some XML representation
So, for example, the user releases a new ear MyApp-1.0.2-ear and places 
it in their central repository. They then interact with Geronimo to 
deploy the app which generates a runnable configuration (e.g. right JNDI 
binding, CMP config, whatever). This configuration comprises a set of 
URLs that form the classpath entries and a data stream that represents 
the GBeans.

When this is distributed, we tell each target about the component and 
the config data. The node downloads the code from the repository, 
expands out any archives (e.g. exploding an ear to extract a war), and 
builds the runtime config comprising a list of local classpath entries 
and the runtime configuration.

When the target is started, then a new classspace is created to provide 
the classpath and the config is loaded and used to instanciate the 
GBeans. We then start each GBean and let the dependency manager ensure 
they start in the correct sequence.

This solves a couple of problems:
a) the config can be built in isolation from the running system.
   So the deployment tool can load any new classes from the component,
   and construct the runtime state without interfering with a running
   system. The deployment tool could also validate the config.
b) the runtime state is not loaded until the classpath is set up
   this means all the chicken/egg issues we have now go away
c) all the kernel needs is the config store - the classpath + the config
   data. This can be moved between instances as needed, allowing for
   easy integration of additional processing nodes in an
   embedded/cluster architecture
As this is a significant change to the deployment architecture I was 
working on this offline over the break to avoid disruption. If people 
think it is worth checking in as a revolution branch I can do that.

--
Jeremy