Jeremy Boynes wrote:
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?
Ah for this one I guess I got confused between spec related discussions,
Jim's changes, and additional ideas I was playing with. I was looking
for a good name for the information describing a component, and since
we're always talking about how nice POJOs and JavaBeans are these days,
ComponentInfo sounded like BeanInfo and seemed to get us closer to our
ideal JavaBean based world :) I'm happy to get back to ComponentType if
people don't like ComponentInfo.
- 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)?
I'd like to keep lists for now. Lists are easier to use than maps, and
this is how most models out there represent 0/1..n relationships. I'll
create a JIRA issue to evaluate what things would look like if we
changed to maps later maybe, but I don't think we should do this now
before our JavaOne release.
- 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.
Agreed, I'm holding off on this for now.
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.
that's why
+1 for merging
Ok, thanks for reviewing, I'll wait until tomorrow to give others an
opportunity to take a look before I do the merge.
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
--
Jean-Sebastien
