On Apr 23, 2009, at 2:19 PM, David Blevins wrote:
Curious what Dain's input on this might be. A lot of this "deep
object graph" work was driven by Plexus which of course also has
post construct callbacks.
The ObjectGraph code was written to address the problems with
coordinating the creation of several complex objects. The idea was to
abstract the hardest bits of a DI system without defining the user
facing DI apis, so those of us writing DI systems can collaborate on
the hardest bits. I wrote this stuff wile working on Plexus, but due
to the current Plexus design, I couldn't get it in.... long story
In JEE and Plexus, post construct callbacks happen only after an
object is fully constructed (constructor and all setters), so those
system collect the final objects and call the post construct methods
themselves. This could be moved to ObjectRecipe without hurting any
existing users since it is additive.
On Apr 23, 2009, at 2:02 AM, Guillaume Nodet wrote:
Another thing is related to initialization of beans and cyclic
dependencies.
The Option.LAZY_ASSIGNMENT option can be set on a recipe to allo
references to be injected at a later time when they are created and
break cyclic dependencies. However, calling an initialization method
must be done only when the instance has been fully constructed. I
think it would be easier if xbean-reflect has built-in support for
calling initializing methods on beans...
On Thu, Apr 23, 2009 at 10:46, Guillaume Nodet <[email protected]>
wrote:
When trying to implement the dedens-on attribute for blueprint, I
had
to find my way in xbean-reflect about constructor recipes and nested
recipes.
In the ObjectRecipe, a factory-method can be set so that the
object is
built by calling a static method or an instance method.
This will be very useful when implementing the factory stuff in
blueprint.
However, I think there is a mismatch here.
In xbean-reflect, the recipe is used to create both the factory (in
case of an instance factory), then the factory method is called to
create the final object. In blueprint, there is a notion of
factory
component, which should be built by its own recipe, then used as a
reference to create the object using arguments if any, then
populating
the created beans using properties.
I'd like to enhance xbean-reflect to support such factory
instances by
references, but it would break any existing code relying on the
current factory mechanism.
Sounds like a good idea. Originally when I wrote this code, static
factories and instance factories were separate, but later is
simplified it. Normally an instance factory was on a custom class, so
I could always write it so it worked. With 299 and blueprint (no idea
what that is), I think we need to go back the more complex model.
Is there a need to support backward compatibility on this ?
Not really. Just need to make sure it works in OpenEJB, Plexus and
Geronimo. I'll have to check but I don't think Plexus uses factory
methods at all. OpenEJB definitely uses the shared static/instance
factory method idea.
I say do it, and we can all discuss the APIs when you get something
working.
-dain
