geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: ModuleBuilder - add initENC after addGBeans
Date Thu, 02 Mar 2006 12:22:25 GMT
Dain Sundstrom wrote:

> On Mar 1, 2006, at 10:06 AM, Dain Sundstrom wrote:
>
>> On Mar 1, 2006, at 7:27 AM, David Jencks wrote:
>>
>>> On Mar 1, 2006, at 3:56 AM, Gianny Damour wrote:
>>>
>>>> Hi,
>>>>
>>>> I think that we need to split ModuleBuilder.addGBeans into two  
>>>> methods: addGBeans and initENC. addGBeans implementations perform  
>>>> GBean registrations as per the current approach. initENC is  
>>>> invoked after the addGBeans phase and implementations use this  
>>>> callback to build the ENC.
>>>>
>>>> The issue with the current implementation is that it is  impossible 
>>>> to bind a GBean reference to the ENC if the referenced  GBean is 
>>>> defined by a module which has not yet been processed by  addGBeans. 
>>>> For instance, if a module A references a GBean added  by a module B 
>>>> and if module A is processed before module B, then  it is 
>>>> impossible to locate the referenced GBean as it has not yet  been 
>>>> added to the registry.
>>>>
>>>> If there is no objection, I will start to work on it in the next  
>>>> couple of days.
>>>
>>>
>>> I would rather see us reduce the number of module builder phases  
>>> than increase them :-)  So far we have dealt with this problem by  
>>> registering a gbean data for anything that could possibly be  
>>> referenced in the ENC during the initContext phase.  I'm also  
>>> worried that changes of this nature could make merging the  
>>> configid/1.1 changes into trunk almost impossible.
>>
>>
>> Big +1 from me
>
>
> Should clarify... that was a big +1 to David Jencks.  These changes  
> will make configid/1.1 almost impossible to merge.  Also, with the  
> configid changes, we are simplifying (i.e., changing) the way  
> references work, and my guess is you will no longer want to make the  
> proposed change.

Actually, I understood it this way :).

If the simplified way of resolving references being implemented on the 
1.1 branch defers the resolution of GBean references until after the 
registrations of all the GBeans added by the builders, then I assume 
that we no longer want this change.

Anyway, after having thought about it a little bit more, I realized it 
was possible to defer the resolution of GBean references w/o having to 
add an extra method. ENCConfigBuilder.buildComponentContext adds to the 
EARContext a command to build the component context and returns an empty 
Map. In EARConfigBuilder.buildConfiguration, after the addGBeans phase, 
one retrieves and executes the command previously added to the 
EARContext. It is quite a pity that I did not think about it before my 
email :(

Thanks,
Gianny

>
> -dain
>



Mime
View raw message