geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [bluprint + xbean-reflect] Use of factories
Date Thu, 23 Apr 2009 16:56:28 GMT
On Thu, Apr 23, 2009 at 18:52, David Blevins <> wrote:
> 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?

Just meaning that the factory is itself a bean usually created with
its own recipe.
So the properties on the recipe that uses the factory will be used to:
  * call the factory method
  * populate the created beans with properties

>> , 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.

Yes, if it's needed.  The new way is just more powerful than the old
one, so if it's not a requirement, i would just get rid of the
previous factory system.

> -David

Guillaume Nodet
Open Source SOA

View raw message