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
