Re: [bluprint + xbean-reflect] Use of factories
|
View:
New views
15 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
|
|
|
Re: [bluprint + xbean-reflect] Use of factories
by gnodet
::
Rate this Message:
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) {} public void setB(int g) {} } class YUVColor extends Color { public void setY(int y) {} public void setU(int u) {} public void setV(int v) {} } then, we'd have: ObjectRecipe colorFactoryRecipe = new ObjectRecipe(ColorFactory.class) colorFactoryRecipe.setProperty("foo", "bar"); factory ObjectRecipe rgbRecipe = new ObjectRecipe(); rgbRecipe.setInstanceFactory(colorFactoryRecipe); rgbRecipe.setMethodFactory("createColor"); rgbRecipe.setProperty("type", "rgb"); rgbRecipe.setProperty("r", "255"); rgbRecipe.setProperty("g", "255"); rgbRecipe.setProperty("b", "255"); If we have: class ColorFactory { public static Color createColor(String type) { } } then we'd have: ObjectRecipe redRecipe = new ObjectRecipe(); redRecipe.setClassName(ColorFactory.class); redRecipe.setInstanceFactory(null); redRecipe.setMethodFactory("createColor"); redRecipe.setProperty("r", "255"); But Jarek is right, and we might have other problems with the way the arguments matching is done. On Thu, Apr 23, 2009 at 19:26, David Blevins <david.blevins@...> wrote: > [cc'ing the xbean-dev@... list] > > On Apr 23, 2009, at 9:56 AM, Guillaume Nodet wrote: > >>>> >>>> In blueprint, there is a notion of factory >>>> component, which should be built by its own recipe >>> >>> With you so far. >>> >>>> , then used as a reference to create the object using arguments if any >>> >>> Not sure what "used as a reference" means. Also not sure what "using >>> arguments" means. Are the arguments somehow different than the >>> properties >>> in a recipe? Where do they come from? >> >> Just meaning that the factory is itself a bean usually created with >> its own recipe. >> So the properties on the recipe that uses the factory will be used to: >> * call the factory method >> * populate the created beans with properties >> >>>> , then populating the created beans using properties. >>> >>> So the factory is allowed to create several beans and I guess is kept >>> around >>> and the resulting beans should be injected with it's own set of >>> properties? >> >> Right > > So is this basically what you're talking about? (making up some api here) > > ObjectRecipe colorFactoryRecipe = new ObjectRecipe(ColorFactory.class) > colorFactoryRecipe.setProperty("foo", "bar"); // set the properties for the > factory > > ColorFactory colorFactory = (ColorFactory) factoryRecipe.create(); > > ObjectRecipe redRecipe = new ObjectRecipe(); > redRecipe.setInstanceFactory(colorFactory); > redRecipe.setProperty("r", "255"); > redRecipe.setProperty("g", "0"); > redRecipe.setProperty("b", "0"); > > Color red = (Color) redRecipe.create(); > > ObjectRecipe blueRecipe = new ObjectRecipe(); > blueRecipe.setInstanceFactory(colorFactory); > blueRecipe.setProperty("r", "0"); > blueRecipe.setProperty("g", "0"); > blueRecipe.setProperty("b", "255"); > > Color blue = (Color) redRecipe.create(); > > That the basic idea? > > -David > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com |
|
|
|
|
|
|
|
|
Re: [bluprint + xbean-reflect] Use of factories
by David Blevins
::
Rate this Message:
On Apr 23, 2009, at 12:09 PM, Guillaume Nodet wrote: > The problem is that we'll end up using a very small portion of > xbean-reflect (we don't use even use the property editor package atm). No fair starting that thread while I'm still typing responses to the earlier questions :) -David |
|
|
Re: [bluprint + xbean-reflect] Use of factories
by David Blevins
::
Rate this Message:
Give this a look and see what you think. What we have isn't too far
off. http://svn.apache.org/viewvc/geronimo/xbean/trunk/xbean-reflect/src/test/java/org/apache/xbean/recipe/ScratchPadTest.java?revision=768055&view=markup In regards to argument matching, we'll need to support pure type based approaches to constructor, factory, and method args as well for JCDI (JSR-299) support as well. -David On Apr 23, 2009, at 11:22 AM, Guillaume Nodet wrote: > 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) {} > public void setB(int g) {} > } > > class YUVColor extends Color { > public void setY(int y) {} > public void setU(int u) {} > public void setV(int v) {} > } > > then, we'd have: > > ObjectRecipe colorFactoryRecipe = new ObjectRecipe(ColorFactory.class) > colorFactoryRecipe.setProperty("foo", "bar"); factory > > ObjectRecipe rgbRecipe = new ObjectRecipe(); > rgbRecipe.setInstanceFactory(colorFactoryRecipe); > rgbRecipe.setMethodFactory("createColor"); > rgbRecipe.setProperty("type", "rgb"); > rgbRecipe.setProperty("r", "255"); > rgbRecipe.setProperty("g", "255"); > rgbRecipe.setProperty("b", "255"); > > If we have: > > class ColorFactory { > > public static Color createColor(String type) { } > } > > then we'd have: > > ObjectRecipe redRecipe = new ObjectRecipe(); > redRecipe.setClassName(ColorFactory.class); > redRecipe.setInstanceFactory(null); > redRecipe.setMethodFactory("createColor"); > redRecipe.setProperty("r", "255"); > > > But Jarek is right, and we might have other problems with the way the > arguments matching is done. > > On Thu, Apr 23, 2009 at 19:26, David Blevins > <david.blevins@...> wrote: >> [cc'ing the xbean-dev@... list] >> >> On Apr 23, 2009, at 9:56 AM, Guillaume Nodet wrote: >> >>>>> >>>>> In blueprint, there is a notion of factory >>>>> component, which should be built by its own recipe >>>> >>>> With you so far. >>>> >>>>> , then used as a reference to create the object using arguments >>>>> if any >>>> >>>> Not sure what "used as a reference" means. Also not sure what >>>> "using >>>> arguments" means. Are the arguments somehow different than the >>>> properties >>>> in a recipe? Where do they come from? >>> >>> Just meaning that the factory is itself a bean usually created with >>> its own recipe. >>> So the properties on the recipe that uses the factory will be used >>> to: >>> * call the factory method >>> * populate the created beans with properties >>> >>>>> , then populating the created beans using properties. >>>> >>>> So the factory is allowed to create several beans and I guess is >>>> kept >>>> around >>>> and the resulting beans should be injected with it's own set of >>>> properties? >>> >>> Right >> >> So is this basically what you're talking about? (making up some api >> here) >> >> ObjectRecipe colorFactoryRecipe = new >> ObjectRecipe(ColorFactory.class) >> colorFactoryRecipe.setProperty("foo", "bar"); // set the >> properties for the >> factory >> >> ColorFactory colorFactory = (ColorFactory) factoryRecipe.create(); >> >> ObjectRecipe redRecipe = new ObjectRecipe(); >> redRecipe.setInstanceFactory(colorFactory); >> redRecipe.setProperty("r", "255"); >> redRecipe.setProperty("g", "0"); >> redRecipe.setProperty("b", "0"); >> >> Color red = (Color) redRecipe.create(); >> >> ObjectRecipe blueRecipe = new ObjectRecipe(); >> blueRecipe.setInstanceFactory(colorFactory); >> blueRecipe.setProperty("r", "0"); >> blueRecipe.setProperty("g", "0"); >> blueRecipe.setProperty("b", "255"); >> >> Color blue = (Color) redRecipe.create(); >> >> That the basic idea? >> >> -David >> >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > |
|
|
|
|
|
Re: [bluprint + xbean-reflect] Use of factories
by David Blevins
::
Rate this Message:
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@...> 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@...> >> 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 > |
|
|
Re: [bluprint + xbean-reflect] Use of factories
by gnodet
::
Rate this Message:
Thanks, looks like we can already do a lot. I now remember seeing
this PassThroughInterface in gbean code. Anyway, I think we're still missing on construct, even in you not supported yet use cases: in the testReusableInstanceFactory() example, we need to allow the color recipe to be created by using the factoryRecipe instead of the build factory, so that the graph construction will take that into account. So it should not be : ObjectRecipe factoryRecipe = new ObjectRecipe(ColorInstanceFactory.class); factoryRecipe.setProperty("foo", "bar"); ColorInstanceFactory colorInstanceFactory = (ColorInstanceFactory) factoryRecipe.create(); ObjectRecipe recipe = new ObjectRecipe(colorInstanceFactory); recipe.setFactoryMethod("createColor"); but rather ObjectRecipe factoryRecipe = new ObjectRecipe(ColorInstanceFactory.class); factoryRecipe.setProperty("foo", "bar"); ObjectRecipe recipe = new ObjectRecipe(factoryRecipe); recipe.setFactoryMethod("createColor"); On Thu, Apr 23, 2009 at 23:14, David Blevins <david.blevins@...> wrote: > Give this a look and see what you think. What we have isn't too far off. > > http://svn.apache.org/viewvc/geronimo/xbean/trunk/xbean-reflect/src/test/java/org/apache/xbean/recipe/ScratchPadTest.java?revision=768055&view=markup > > In regards to argument matching, we'll need to support pure type based > approaches to constructor, factory, and method args as well for JCDI > (JSR-299) support as well. > > -David > > On Apr 23, 2009, at 11:22 AM, Guillaume Nodet wrote: > >> 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) {} >> public void setB(int g) {} >> } >> >> class YUVColor extends Color { >> public void setY(int y) {} >> public void setU(int u) {} >> public void setV(int v) {} >> } >> >> then, we'd have: >> >> ObjectRecipe colorFactoryRecipe = new ObjectRecipe(ColorFactory.class) >> colorFactoryRecipe.setProperty("foo", "bar"); factory >> >> ObjectRecipe rgbRecipe = new ObjectRecipe(); >> rgbRecipe.setInstanceFactory(colorFactoryRecipe); >> rgbRecipe.setMethodFactory("createColor"); >> rgbRecipe.setProperty("type", "rgb"); >> rgbRecipe.setProperty("r", "255"); >> rgbRecipe.setProperty("g", "255"); >> rgbRecipe.setProperty("b", "255"); >> >> If we have: >> >> class ColorFactory { >> >> public static Color createColor(String type) { } >> } >> >> then we'd have: >> >> ObjectRecipe redRecipe = new ObjectRecipe(); >> redRecipe.setClassName(ColorFactory.class); >> redRecipe.setInstanceFactory(null); >> redRecipe.setMethodFactory("createColor"); >> redRecipe.setProperty("r", "255"); >> >> >> But Jarek is right, and we might have other problems with the way the >> arguments matching is done. >> >> On Thu, Apr 23, 2009 at 19:26, David Blevins <david.blevins@...> >> wrote: >>> >>> [cc'ing the xbean-dev@... list] >>> >>> On Apr 23, 2009, at 9:56 AM, Guillaume Nodet wrote: >>> >>>>>> >>>>>> In blueprint, there is a notion of factory >>>>>> component, which should be built by its own recipe >>>>> >>>>> With you so far. >>>>> >>>>>> , then used as a reference to create the object using arguments if any >>>>> >>>>> Not sure what "used as a reference" means. Also not sure what "using >>>>> arguments" means. Are the arguments somehow different than the >>>>> properties >>>>> in a recipe? Where do they come from? >>>> >>>> Just meaning that the factory is itself a bean usually created with >>>> its own recipe. >>>> So the properties on the recipe that uses the factory will be used to: >>>> * call the factory method >>>> * populate the created beans with properties >>>> >>>>>> , then populating the created beans using properties. >>>>> >>>>> So the factory is allowed to create several beans and I guess is kept >>>>> around >>>>> and the resulting beans should be injected with it's own set of >>>>> properties? >>>> >>>> Right >>> >>> So is this basically what you're talking about? (making up some api here) >>> >>> ObjectRecipe colorFactoryRecipe = new ObjectRecipe(ColorFactory.class) >>> colorFactoryRecipe.setProperty("foo", "bar"); // set the properties for >>> the >>> factory >>> >>> ColorFactory colorFactory = (ColorFactory) factoryRecipe.create(); >>> >>> ObjectRecipe redRecipe = new ObjectRecipe(); >>> redRecipe.setInstanceFactory(colorFactory); >>> redRecipe.setProperty("r", "255"); >>> redRecipe.setProperty("g", "0"); >>> redRecipe.setProperty("b", "0"); >>> >>> Color red = (Color) redRecipe.create(); >>> >>> ObjectRecipe blueRecipe = new ObjectRecipe(); >>> blueRecipe.setInstanceFactory(colorFactory); >>> blueRecipe.setProperty("r", "0"); >>> blueRecipe.setProperty("g", "0"); >>> blueRecipe.setProperty("b", "255"); >>> >>> Color blue = (Color) redRecipe.create(); >>> >>> That the basic idea? >>> >>> -David >>> >>> >>> >> >> >> >> -- >> 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 |
|
|
Re: [bluprint + xbean-reflect] Use of factories
by gnodet
::
Rate this Message:
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 <gnodet@...> 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@...> 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@...> 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 |
|
|
Re: [bluprint + xbean-reflect] Use of factories
by David Blevins
::
Rate this Message:
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 <gnodet@...> > 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@...> 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@...> 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 > |
|
|
Re: [bluprint + xbean-reflect] Use of factories
by Dain Sundstrom
::
Rate this Message:
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 creation of several complex objects. The idea was to abstract the hardest bits of a DI system without defining the user facing DI apis, so those of us writing DI systems can collaborate on the hardest bits. I wrote this stuff wile working on Plexus, but due to the current Plexus design, I couldn't get it in.... long story In JEE and Plexus, post construct callbacks happen only after an object is fully constructed (constructor and all setters), so those system collect the final objects and call the post construct methods themselves. This could be moved to ObjectRecipe without hurting any existing users since it is additive. > On Apr 23, 2009, at 2:02 AM, Guillaume Nodet wrote: > >> Another thing is related to initialization of beans and cyclic >> dependencies. >> The Option.LAZY_ASSIGNMENT option can be set on a recipe to allo >> references to be injected at a later time when they are created and >> break cyclic dependencies. However, calling an initialization method >> must be done only when the instance has been fully constructed. I >> think it would be easier if xbean-reflect has built-in support for >> calling initializing methods on beans... >> >> On Thu, Apr 23, 2009 at 10:46, Guillaume Nodet <gnodet@...> >> 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. Sounds like a good idea. Originally when I wrote this code, static factories and instance factories were separate, but later is simplified it. Normally an instance factory was on a custom class, so I could always write it so it worked. With 299 and blueprint (no idea what that is), I think we need to go back the more complex model. >>> Is there a need to support backward compatibility on this ? Not really. Just need to make sure it works in OpenEJB, Plexus and Geronimo. I'll have to check but I don't think Plexus uses factory methods at all. OpenEJB definitely uses the shared static/instance factory method idea. I say do it, and we can all discuss the APIs when you get something working. -dain |
|
|
Re: [bluprint + xbean-reflect] Use of factories
by gnodet
::
Rate this Message:
On Fri, Apr 24, 2009 at 19:27, Dain Sundstrom <dain@...> 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 was written to address the problems with coordinating > the creation of several complex objects. The idea was to abstract the > hardest bits of a DI system without defining the user facing DI apis, so > those of us writing DI systems can collaborate on the hardest bits. I wrote > this stuff wile working on Plexus, but due to the current Plexus design, I > couldn't get it in.... long story > > In JEE and Plexus, post construct callbacks happen only after an object is > fully constructed (constructor and all setters), so those system collect the > final objects and call the post construct methods themselves. This could be > moved to ObjectRecipe without hurting any existing users since it is > additive. The only problem is that I need the object to be fully initialized (including the call to the init method afaik) before being injected. If this is not possible (due to cyclic dependencies), a partially object might be injected. >> On Apr 23, 2009, at 2:02 AM, Guillaume Nodet wrote: >> >>> Another thing is related to initialization of beans and cyclic >>> dependencies. >>> The Option.LAZY_ASSIGNMENT option can be set on a recipe to allo >>> references to be injected at a later time when they are created and >>> break cyclic dependencies. However, calling an initialization method >>> must be done only when the instance has been fully constructed. I >>> think it would be easier if xbean-reflect has built-in support for >>> calling initializing methods on beans... >>> >>> On Thu, Apr 23, 2009 at 10:46, Guillaume Nodet <gnodet@...> 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. > > Sounds like a good idea. Originally when I wrote this code, static > factories and instance factories were separate, but later is simplified it. > Normally an instance factory was on a custom class, so I could always write > it so it worked. With 299 and blueprint (no idea what that is), I think we > need to go back the more complex model. The Blueprint spec is being written inside OSGi and is somewhat based on the idea from Spring + Spring DM (an OSGi related companion library for Spring). >>>> Is there a need to support backward compatibility on this ? > > Not really. Just need to make sure it works in OpenEJB, Plexus and > Geronimo. I'll have to check but I don't think Plexus uses factory methods > at all. OpenEJB definitely uses the shared static/instance factory method > idea. > > I say do it, and we can all discuss the APIs when you get something working. Got it. > -dain > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com |
|
|
Re: [bluprint + xbean-reflect] Use of factories
by David Blevins
::
Rate this Message:
On Apr 24, 2009, at 11:09 AM, Guillaume Nodet wrote: > The only problem is that I need the object to be fully initialized > (including the call to the init method afaik) before being injected. > If this is not possible (due to cyclic dependencies), a partially > object might be injected. I had a chat with Rick about that requirement. It's a difficult one to satisfy as is and is one area of the blueprint spec I hope to see improved. If you expand the reference semantics so that you can differentiate between simply having a reference to something and having a reference to something you need to be initialized by the time your init method is called (let's call it a dependency), so many things become easier. For one, you could pretty much ignore any circular references, it's only circular dependencies you need to reject. So complex graphs of objects that all use each other at runtime (post initialization) are no problem at all in any fashion as long as there aren't any cyclic dependencies on the init phase. Second, for dependencies, you wouldn't need to require that init methods be called prior to injection, only that they are called prior to your init method. So then you can construct your graph in one step, then sort it as a list in dependency order, and then simply iterate over it and call init on each object. Very easy. You can even get fancy with what you offer components in their init methods, such as transaction guarantees and other heavier things. Another benefit, perhaps touchy-feely, is that your entire tree is constructed and issues relating to referring to things that don't exist or other invalid references, or data that is to be injected that can't be converted to the target type, etc., are all flushed out before any initialization is done. This is good because init methods can have some pretty heavy logic and it would be really be terrible to get nearly all the way through a large graph only to fail for what is essentially a syntax error. Whether or not you think that is important really depends on if you're more of an interpreted language person or a compiled language person. IMO, being able to provide a guarantee that the graph has been fully constructed and all is well before any init methods are called is a very good guarantee to offer people. -David |
| Free embeddable forum powered by Nabble | Forum Help |
