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 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 <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. > > 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
