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

[Juergen H. <ju...@in...>]

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




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer