Re: [Springframework-developer] Beans with factory-method treated like FactoryBeans

[Colin S. <col...@ex...>]

Some more on this:
  http://forum.springframework.org/viewtopic.php?p=27219#27219


Juergen Hoeller wrote:

>Finally committed.
>
>(It's a busy weekend here: entire apartment freshly painted.)
>
>Juergen
> 
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Juergen Hoeller
>Sent: Sunday, July 10, 2005 9:37 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Beans with factory-method treated
>like FactoryBeans
>
>Hi Colin,
>
>Thanks for your feedback. There have indeed been some tricky issues in the
>factory method handling, mainly in determining the type upfront. Pre 1.2.2
>we simply considered the type undeterminable for all factory methods.
>
>In 1.2.2, we try to figure it out as far as possible, which unfortunately
>led to a potential side effect with too early creation of "factory-bean"
>targets - even before BeanFactoryPostProcessors. This led to the refinement
>that a "factory-method" will only be resolved if the "includeFactoryBeans"
>flag is "true" - which it isn't for BeanFactoryPostProcessors.
>
>You got a point there in that this should only apply to actual
>"factory-bean" references. For a static "factory-method" on the given class,
>we should try to figure out the type statically - as far as possible, even
>with "includeFactoryBeans" being "false". If a bean instance is already
>created, we'll always return the actual type anyway.
>
>I've just refined this accordingly, through only excluding "factory-bean"
>references if "includeFactoryBeans" is off. To figure out the type for a
>factory method, AbstractBeanFactory's "getType" delegates to the newly
>introduced "getTypeForFactoryMethod" now, which creates the object in case
>of a "factory-bean" reference (if appropriate) or checks the return type of
>the static factory method else.
>
>However, we can only clearly determine the type if we either only have a
>single static factory method of the given name or multiple overloaded
>factory methods that all return the same type (there's hardly gonna be any
>other case). Else, we'll return null as "undeterminable" upfront: The actual
>factory method called will only be clear after converting constructor
>arguments and/or autowiring.
>
>Juergen
> 
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Colin Sampaleanu
>Sent: Saturday, July 09, 2005 6:42 PM
>To: spr...@li...
>Subject: [Springframework-developer] Beans with factory-method treated like
>FactoryBeans
>
>Juergen,
>
>I saw you made some changes for how beans with factory-method set are
>treated, so that they are essentially treated closer to being a FactoryBean
>in some respects. I don't necessarilly disagree or anything (and it looks
>like there were some bugs too, in any case), but I'm trying to see the
>rationale for the changes.
>
>- for 1.2.2 in DefaultListableBeanFactory, there is a comment:
>   "* exclude bean definitions with factory method from pre-instantiation
>type matching; pre-instantiate and match beans with factory method /
>"factory-bean" definition".
>- post 1.2.2, there is a comment:
>  "DefaultListableBeanFactory does not create beans with "factory-method"
>for type check if "includeFactoryBeans"=false"
>
>As I see the current code, beans with a factory method get treated
>essentially the same as a FactoryBean. getBeanNamesForType will now only
>match the result of a bean def with a factory-method set if the
>'includeFactoryBeans' arg is set to true, and to get this to happen, the
>bean will actually always be created (via a getBean).
>
>But unless I'm missing something, I think this might be the wrong behaviour
>for static factroy methods. The factory class is known, as well as the
>static factory method with the proper return type. The match can be done
>properly without ever creating the bean. In this respect, I see the static
>factory method being a direct alternative to new/newInstance().
>
>Now a non-static factory method (via a sibling factory-bean ref) is I guess
>a different thing. You could even handle some of those statically if you
>look at the actual factory-bean referenced, and it's just a normal bean, and
>the method declares the return type. But certainly if the referenced
>factory-bean is a FactoryBean itself that's not going to work. So for the
>non-static case I guess it makes sense to keep the bean def with a
>factory-bean ref treated just like a FactoryBean; it's simpler and more
>deterministic.
>
>What do you think / can you clarify?
>
>Colin
>
>--
>Colin Sampaleanu
>Interface21 Principal Consultant
>Spring Training, Consulting and Support - "From the Source"
>http://www.springframework.com
>
>  
>

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com