geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: [bluprint + xbean-reflect] Use of factories
Date Thu, 23 Apr 2009 16:52:40 GMT

On Apr 23, 2009, at 1:46 AM, Guillaume Nodet 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.

Same basic technique is used when the static factory method has  
arguments; the recipe is used to satisfy the arguments as well as for  
hydrating the resulting object.

>    In blueprint, there is a notion of factory
> component, which should be built by its own recipe

With you so far.

> , then used as a reference to create the object using arguments if any

Not sure what "used as a reference" means.  Also not sure what "using  
arguments" means.  Are the arguments somehow different than the  
properties in a recipe?  Where do they come from?

> , then populating the created beans using properties.

So the factory is allowed to create several beans and I guess is kept  
around and the resulting beans should be injected with it's own set of  
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.
> Is there a need to support backward compatibility on this ?

It's used pretty heavily, so definitely, yes.

Likely we can find some way to support both.

-David


Mime
View raw message