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 Fri, 24 Apr 2009 16:49:58 GMT
There's a feature (and a bug) in there for this.  You can prefix the  
property name with the class name and the property will not be  
targeted at other classes.  It's primarily for private field injection  
where the same property exists in both a parent and a subclass.

I recall there's a bug in that it messes up constructor injection.

-David

On Apr 23, 2009, at 11:30 PM, Guillaume Nodet wrote:

> 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 <gnodet@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 <jgawor@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  
>>> <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.
>>>> 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
>


Mime
View raw message