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 21:27:11 GMT
To add onto this thought process, a lot of these features are also  
needed by the Java Context and Dependency Injection (JCDI, JSR-299)  
specification.  It has type base constructor args, reusable instance  
factories, and some other things like support for setters that have  
multiple arguments.

JSR-299 is being heavily reworked so that it is pretty much just "Java  
EE dependency injection version 2.0"   We'll need all this stuff for  
Java EE 6.

-David

On Apr 23, 2009, at 11:28 AM, 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 <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
>


Mime
View raw message