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 <[email protected]> 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 >
