geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Deployment problem - need to load classes
Date Fri, 26 Dec 2003 22:38:35 GMT
I have run into a problem with the way the Planners try to build the 
configuration information for the GMBeans they are trying to deploy.

The specific issue is in identifying which cmp-fields for a CMP Entity 
are part of a compound primary key. This information is not contained in 
the meta-datal; instead, the meta-data defines the Class of the PK and 
the cmp-fields are the public Fields of that Class. The planner can't 
figure this out without loading the Class for the PK, which it can't do 
because the class-space has not yet been started. This means the 
configuration information cannot be fully generated by the Planner, or 
the associated Task's, but can only be done during the start phase of 
the EJBContainer.

This is not really new - for example, the proxy factories themselves are 
not created until start for a similar reason (can't load the interface 
Class in order to implement it). The difference is though that in 
existing cases the configuration does not change.

We can do the same thing here, but my concern is that more and more work 
  is being done in the start phase. The only reason for this is the need 
to load classes - the actual configuration is the same every time. This 
both increases the workload to start and increases the opportunity for 
failure (for example, if there is no cmp-field defined for a PK member 
we have a misconfigured system which cannot be fixed without intervention).

The ultimate solution I think is to ensure that tasks are added to the 
deployment plan that ensure a new class-space generation is created at 
the start of plan execution. The Planner then create tasks that can run 
knowing that the class-space is set up so that any Class'es will be 
loadable. The plan executes to completion in the context of this new 
class-space. If an error occurs, then it is simply discarded; if the 
plan completes successfully, the class-spaces are swapped and the 
GMBeans started.

This makes the deployment phases:
* Distribution, where code and meta-data are made available
   to the targeted nodes
* ClassSpace Definition, where the planners add any code source into
   the target classspace
* Task Scheduling, where the planners create the deployment Tasks and
   schedule them for execution
* ClassSpace start, where the new ClassSpace is created
* Plan Execution, where the tasks are executed in order and generate
   the persistent configuration
* GMBean start, which starts the configuration
* Old ClassSpace Shutdown, where the (now replaced) configuration is
   shutdown, workload is switched to the new version, and the older
   Class'es get GC'ed

This has an impact on existing containers. For example, the 
EJBContainer's no longer need to wait until start() to load their 
classes and create code-dependent configuration. This can instead be 
handled by the deployment Task and pushed into the container during 

This is a big enough change that it kind of worries me and I would like 
a second opinion before starting down this track. Thoughts?


View raw message