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