On Apr 23, 2009, at 2:19 PM, David Blevins wrote:
Curious what Dain's input on this might be. A lot of this deep
object graph work was driven by Plexus which of course also has
post construct callbacks.
The ObjectGraph code was written to address the problems with
coordinating the
On Fri, Apr 24, 2009 at 19:27, Dain Sundstrom d...@iq80.com wrote:
On Apr 23, 2009, at 2:19 PM, David Blevins wrote:
Curious what Dain's input on this might be. A lot of this deep object
graph work was driven by Plexus which of course also has post construct
callbacks.
The ObjectGraph code
Right, but in addition to instanceFactory, we also need to provide the
methodFactory.
So if we have
class ColorFactory {
public void setFoo(String foo) { }
public Color createColor(String type) { }
}
class RGBColor extends Color {
public void setR(int r) {}
public void setG(int g) {}
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
Curious what Dain's input on this might be. A lot of this deep
object graph work was driven by Plexus which of course also has post
construct callbacks.
-David
On Apr 23, 2009, at 2:02 AM, Guillaume Nodet wrote:
Another thing is related to initialization of beans and cyclic
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
