geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <da...@coredevelopers.net>
Subject Re: Deployment problem - need to load classes
Date Sat, 27 Dec 2003 05:46:41 GMT
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
>


Mime
View raw message