I'm also in the process of making some changes to the eventing system
(e.g. fireEvent) - Sebastien can we coordinate yours and mine?
On Apr 11, 2006, at 12:52 PM, Jean-Sebastien Delfino wrote:
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
