geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Deployment problem - need to load classes
Date Mon, 29 Dec 2003 20:40:48 GMT

Now that the component model has been simplified I think we can also 
simply the deployment system and I think this plan is exactly the 
doctor ordered.


  * Dain Sundstrom
  * Partner
  * Core Developers Network

On Dec 26, 2003, at 11:46 PM, David Jencks wrote:

> Well, today I was wondering a bit about why the class loading should 
> happen in the container start method...
> I think this proposal is a really good idea.  I've been writing up 
> code to set up the TxnPolicies per method and I am forced to do more 
> than I'd like in the container start method.  I think the 
> DeployXXXContainer tasks would be a much better place.
> So far I haven't thought of any problems with this.  For me, I'd like 
> you to go ahead, if problems show up we will deal with them.
> thanks
> david jencks
> On Friday, December 26, 2003, at 02:38 PM, Jeremy Boynes wrote:
>> 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 
>> construction/initialization.
>> 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?
>> -- 
>> Jeremy

View raw message