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
