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
