geronimo-xbean-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 Fri, 24 Apr 2009 06:30:42 GMT
Another thing: when using constructor args or factory method
arguments, to make sure there will no conflict with a property to be
set on the created object, i think we can use dummy names.  For

        ObjectRecipe recipe = new ObjectRecipe(ColorInstanceFactory.class);
        recipe.setConstructorArgNames(new String[]{"#arg0"});
        recipe.setProperty("#arg0", RGBColor.class.getName());
        recipe.setProperty("foo", "bar");
        recipe.setProperty("r", "255");

It seems to work.  The main drawback is that it won't do arguments
reordering automatically afaik.  So we'd still need to enhance this

On Thu, Apr 23, 2009 at 20:28, Guillaume Nodet <> wrote:
> Right, but it might we worth considering enhancing xbean-reflect to
> better support our needs.
> For example initialization and destruction methods are now wired in
> blueprint, but a better place would be xbean imho.
> Constructor injection is a bit of a magic in xbean right now, and
> there's no clear difference betweens arguments passed to constructors
> or factory methods and properties.
> I think we should have the core ioc engine (xbean-reflect) support
> most of our needs so that we could do all the parsing and wiring
> completely with xbean.  Even scopes may be handled by xbean and maybe
> also dynamic dependencies that i've just plugged in.
> I agree to put everything in blueprint for now, but it may be better
> to refactor and enhance xbean to be more powerfull, and blueprint
> would only implement the OSGi bits or other specific things.
> On Thu, Apr 23, 2009 at 19:19, Jarek Gawor <> wrote:
>> Guillaume,
>> I've been working on the constructor injection and factory method for
>> blueprint services and I'm convinced that we can't use the factory
>> stuff that's built-in into the xbean-reflect because we have to do all
>> this parameter matching and re-ordering bits. But as long as
>> xbean-reflect will allow us to provide our own Factory implementation
>> we should be ok. So I'm not looking into changing the existing factory
>> xbean-reflect code but instead I'm looking into changing the
>> xbean-reflect code to have better extensibility so that we can provide
>> our own factory classes or our own recipe classes (that reuse a bunch
>> xbean-reflect code).
>> Jarek
>> On Thu, Apr 23, 2009 at 4: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.    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.
>>> Is there a need to support backward compatibility on this ?
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog:
>>> ------------------------
>>> Open Source SOA
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> Open Source SOA

Guillaume Nodet
Open Source SOA

View raw message