I'm looking at the support for FactoryBean beans in Spring ME.
As far as I can tell, FactoryBeans aren't supported when they are
defined as a top-level bean (i.e. they only seem to work when the
definition is nested inside another bean definition).
My understanding of the implementation is as follows:
* Nested (i.e. non-public or not 'top-level') instances are created in
a method named 'createXXX'.
* The 'create' method for FactoryBean beans always returns java.lang.Object.
* The results of all 'create' methods (FactoryBean or otherwise) are
cast to the type of the source when used.
I've been thinking about how to support FactoryBeans as top-level
beans. I don't think it makes sense to use the same approach of just
casting source values when they are used. Because an InstanceReference
doesn't contain a reference to the source bean, every single
constructor argument and setter argument would need to be cast (in
case it is a FactoryBean), which would make the generated code very
difficult to follow.
The solution I'd like to propose is to add a third pass (augmentation)
in the processing, that augments each 'sink' (constructor or setter
arg) to indicate whether a cast is required in the generated code.
Then, getXXX methods for top-level FactoryBean instances can declare a
return type of java.lang.Object, and these values would be cast at the
use-site. Hopefully, it would also be possible to consolidate some of
the code template, reducing duplication between public and non-public
instances.
The reason that the extra pass would be required is that the decision
of whether or not to cast at a given sink depends on the source, and
the QDoxAugmentation does not necessarily process the bean graph in
topological order of dependencies.
Does this make sense? Any other ideas? Should I prepare a patch?
Thanks,
Martin
Thanks for the support! :o)
Martin
I've now prepared a patch for this issue, based on the approach I described.
The last two commits of my topic/factory-beans branch are relevant:
https://github.com/mart/spring-me/commits/topic%2Ffactory-beans
The branch is based on my earlier pull request for alias support. If
that gets merged, then I'll tidy up and create another pull request
for the factory bean stuff.
Martin
Sorry for not getting back to you on this. Awfully busy in my day job. (Did I say day job? It actually is starting to get a night job as well.) I *will* take a look at the changes you made. Perhaps tonight, but I will aim to look at it at least before the end of the week.
Wilfred
> --
> You received this message because you are subscribed to the Google Groups "Spring ME" group.
> To post to this group, send email to spri...@googlegroups.com.
> To unsubscribe from this group, send email to spring-me+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/spring-me?hl=en.
>
On Wed, Mar 30, 2011 at 4:31 PM, Wilfred Springer <wil...@flotsam.nl> wrote:
> Sorry for not getting back to you on this. Awfully busy in my day job. (Did I say day job? It actually is starting to get a night job as well.) I *will* take a look at the changes you made. Perhaps tonight, but I will aim to look at it at least before the end of the week.
There's no hurry. I'm actually off on holiday from this Friday until
11th April, so whenever's convenient for you.
What's the easiest way to work? Do you want to review just the 'alias'
stuff as it is in master first?
Or would it be easier if I fix up the factory bean work and merge it
all into the same branch?
Martin
Martin