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

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

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