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
example:
ObjectRecipe recipe = new ObjectRecipe(ColorInstanceFactory.class);
recipe.setFactoryMethod("createColor");
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
bit.
On Thu, Apr 23, 2009 at 20:28, Guillaume Nodet <gno...@gmail.com> 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 <jga...@gmail.com> 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 <gno...@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.
>>> Is there a need to support backward compatibility on this ?
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
