geronimo-xbean-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: [bluprint + xbean-reflect] Use of factories
Date Fri, 24 Apr 2009 17:27:43 GMT
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 <gnodet@gmail.com>  
>> 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

Mime
View raw message