geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <da...@coredevelopers.net>
Subject Re: Any plans on Validator?
Date Fri, 02 Jan 2004 05:48:20 GMT
I don't understand a couple of things about your idea yet.

1. Why isn't the set of urls another g-bean, namely a ClassSpace mbean? 
  I'd think this mbean could drive the acquisition of the jars from the 
repository.

2. Why would you have the deploying servers sort the plans rather than 
have the deployer framework sort them?  What would result in different 
orders on different machines?

3. Is it necessary to specify the serialization mechanism for g-bean 
config?  I'd like to avoid over-reliance on xml and keep it easy to 
deploy everything in code with no xml or dds in sight.

If it doesn't break anything important I think it's worth considering 
just checking it in.

david jencks


On Thursday, January 1, 2004, at 08:21 PM, Jeremy Boynes wrote:

> 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
>


Mime
View raw message