geronimo-xbean-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [bluprint + xbean-reflect] Use of factories
Date Fri, 24 Apr 2009 18:09:47 GMT
On Fri, Apr 24, 2009 at 19:27, Dain Sundstrom <> 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 <> 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

Guillaume Nodet
Open Source SOA

View raw message