Re: Assembly model changes

[Jean-Sebastien Delfino <js...@apache.org>]

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

Re: Assembly model changes

[Jim Marino <ji...@gmail.com>]

O.K. sorry if it gave you a conflict - let me know if you have an  
issue with the tests and I can try and help out if possible.

Jim

On Apr 12, 2006, at 8:25 AM, Jean-Sebastien Delfino wrote:

> Jim Marino wrote:
>
>> I just changed the event firing API. I don't think those will  
>> impact any of your stuff (I just checked them in). I think the  
>> refactorings around extension points may impact your stuff and  
>> vice versa.  Let's discuss tomorrow.
>>
>> Jim
>>
>>
>> On Apr 11, 2006, at 7:58 PM, Jean-Sebastien Delfino wrote:
>>
>>
>>> Jim Marino wrote:
>>>
>>>
>>>> I'm also in the process of making some changes to the eventing  
>>>> system (e.g. fireEvent) - Sebastien can we coordinate yours and  
>>>> mine?
>>>>
>>>>
>>>>
>>> Sure. Jim, can you tell us a little more about your changes, what  
>>> projects they impact? and when you're planning to check them in?  
>>> Then we can decide how best to proceed to minimize the merging  
>>> pain. Thanks.
>>>
>>> --Jean-Sebastien
>>>
>>>
>>>
>>
>>
>>
> Jim,
> I'm merging with your changes now, it doesn't look too bad there  
> are just a few conflicts. If all the tests pass after the merge  
> I'll check the changes in.
>
> -- 
> Jean-Sebastien
>
>

Re: Assembly model changes

[Jean-Sebastien Delfino <js...@apache.org>]

Jim Marino wrote:
> I just changed the event firing API. I don't think those will impact 
> any of your stuff (I just checked them in). I think the refactorings 
> around extension points may impact your stuff and vice versa.  Let's 
> discuss tomorrow.
>
> Jim
>
>
> On Apr 11, 2006, at 7:58 PM, Jean-Sebastien Delfino wrote:
>
>> Jim Marino wrote:
>>
>>> I'm also in the process of making some changes to the eventing 
>>> system (e.g. fireEvent) - Sebastien can we coordinate yours and mine?
>>>
>>>
>> Sure. Jim, can you tell us a little more about your changes, what 
>> projects they impact? and when you're planning to check them in? Then 
>> we can decide how best to proceed to minimize the merging pain. Thanks.
>>
>> --Jean-Sebastien
>>
>>
>
>
Jim,
I'm merging with your changes now, it doesn't look too bad there are 
just a few conflicts. If all the tests pass after the merge I'll check 
the changes in.

-- 
Jean-Sebastien

Re: Assembly model changes

[Jim Marino <jm...@myromatours.com>]

I just changed the event firing API. I don't think those will impact  
any of your stuff (I just checked them in). I think the refactorings  
around extension points may impact your stuff and vice versa.  Let's  
discuss tomorrow.

Jim


On Apr 11, 2006, at 7:58 PM, Jean-Sebastien Delfino wrote:

> Jim Marino wrote:
>
>> I'm also in the process of making some changes to the eventing  
>> system (e.g. fireEvent) - Sebastien can we coordinate yours and mine?
>>
>>
> Sure. Jim, can you tell us a little more about your changes, what  
> projects they impact? and when you're planning to check them in?  
> Then we can decide how best to proceed to minimize the merging  
> pain. Thanks.
>
> -- 
> Jean-Sebastien
>
>

Re: Assembly model changes

[Jean-Sebastien Delfino <js...@apache.org>]

Jim Marino wrote:
> I'm also in the process of making some changes to the eventing system 
> (e.g. fireEvent) - Sebastien can we coordinate yours and mine?
>
Sure. Jim, can you tell us a little more about your changes, what 
projects they impact? and when you're planning to check them in? Then we 
can decide how best to proceed to minimize the merging pain. Thanks.

-- 
Jean-Sebastien

Re: Assembly model changes

[Jim Marino <ji...@gmail.com>]

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
>
>