A couple of questions inline Jean-Sebastien Delfino wrote: > - A few renames, Aggregate to Composite, AggregatePart to Part, > SimpleComponent to AtomicComponent, ComponentType to ComponentInfo, more > in line with the current spec discussions and Jim's latest changes to > the core runtime as well.
Good stuff but ComponentInfo surprised me as I've not heard that - did that come from Jim's changes? > - Changed the handling of the maps of Components, EntryPoints, > ExternalServices, ConfiguredReferences, etc. now populated immediately > as you add objects to the model so that loaders can retrieve these > objects by name. Do we still need list functionality or could we just use maps for these things (with an add() helper method on the interface to simplify model construction)? > - Simplified the logic in some of the initialize() and freeze() methods. > > I am debating the usefulness of the freeze() methods, and would like to > get thoughts from the other people in the group. What do people think > about merging freeze and initialize()? or getting rid of this freeze > capability altogether? initialize was there to support post-processing after load as the loader could not add in extra stuff (e.g. by reading sidefiles). We can now do that and have a couple of cases where we actually want the loader to do extra work (e.g. importing WSDLs and SDO type definitions). I think we may be able to remove initialize as well. We still have runtime code that can retieve model objects and freeze was designed to prevent inadvertent changes to the model from messing up that code. We have TODOs to get rid of this (e.g. removing getAggregate()) so I would be OK removing freeze if we accelerate removal of getAggregate() and similar model leaks. > I have not added Autowire to the model yet, I still need to get my head > around Autowire before I do that. > I wouldn't rush on that just yet - I think we need to think a little more about the mechanism for defining autowire constraints. > Next, I'm planning to add Java5 annotations to the model interfaces to > declare the mapping between the model classes and the corresponding XSD > artifacts from sca-core.xsd. I also have a little more cleanup to do in > some of the classes, but I think I've reached a stable enough point now > with the rest of the runtime working with this model. > > I had to catch up with changes in the main stream several times while I > was working in that branch and had a real hard time merging and > resolving conflicts... so if there is no objection, I would like to > merge this code back into the main code stream soon, tomorrow ideally, > before things get out of sync and I run into a nightmare of conflicts > again... Could people take a look and see if this updated model looks > reasonable before I do that? Thanks. > +1 for merging I did notice that many of the changes were just renames. These are fairly simple changes which impact a lot of files and are prime candidates for causing conflicts. However, the change itself it very easy to review/test as it's just a rename. Perhaps some of the conflicts could have been avoided if each one of these was done separately (little and often). -- Jeremy
