geronimo-xbean-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: [bluprint + xbean-reflect] Use of factories
Date Sat, 25 Apr 2009 00:08:57 GMT

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  

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  


View raw message