Merge pull request #6 from dsyer/SPR-8683

Added test cases for SPR-8683
Simplify and demonstrate workaround for SPR-8639

As originally submitted, SPR-8639 used ProxyFactoryBean to apply
MyInterceptor to beans A, B and C.

Typically this works fine, but because of a subtle circular dependency
being introduced due to A and B depending on C and C needing to autowire
D, the PFBs for A and B are prematurely queried for their type (to see
if they are autowire candidates for C) and this trigger a
BeanAlreadyInCreation exception that is subsequently suppressed.

This is a very specific use case and highly unlikely to be reproduced
by other users with any frequency.  However, we will address it even if
only by allowing the original exception to propagate fully.

In the meantime, I have refactored the test case to demonstrate use of
BeanNameAutoProxyCreator in lieu of the original ProxyFactoryBean, and
this approach is better in every way: it is more concise, more readable,
requires fewer bean definitions, and best of all does not suffer from
the above-mentioned bug.

Issue: SPR-8639
Reproduce SPR-8639 failure in anticipation of fix

This change re-introduces ProxyFactoryBean usage to demonstrate the
issue described in the previous commit.  Notice that debug logging is
enabled.  The following log statement documents 'ignoring' (suppressing)
the underlying exception.

To fix this issue, we'll see about allowing this exception to propagate
when dealing with ProxyFactoryBeans that do not have a fixed object type
that can be determined by static generics analysis or a call to
getObjectType on an early FactoryBean reference.

DEBUG: org.springframework.beans.factory.support.DefaultListableBeanFactory
- Ignoring bean creation exception on FactoryBean type check:
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'b' defined in class path resource
[org/springframework/issues/ReproTests-context.xml]: Cannot create inner
bean 'org.springframework.issues.B#7e9ffe3f' of type
[org.springframework.issues.B] while setting bean property 'target';
nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'org.springframework.issues.B#7e9ffe3f'
defined in class path resource
[org/springframework/issues/ReproTests-context.xml]: Cannot resolve
reference to bean 'c' while setting bean property 'c'; nested exception
is org.springframework.beans.factory.BeanCurrentlyInCreationException:
Error creating bean with name 'c':
org.springframework.beans.factory.FactoryBeanNotInitializedException:
Cannot determine target class for proxy

Issue: SPR-8639
Add project for SPR-8725
SPR-8714 repro project
Add repro project for SPR-8711
Merge pull request #7 from srgrodeon/master

Test case for rest template 404
Add missing @ResponseBody to controller method
Add test cases to SPR-8714
SPR-8769
SPR-8769
"Add repro project for SPR-8813"
Merge pull request #9 from madisparn/master

Add repro project for SPR-8813
Simplify
Simplify further

Everything based on @Configuration classes, no XML. Register everything
explicitly; no component scanning. Remove MyPropertyPlaceholderConfigurer,
my.properties etc; @Value injection still occurs without them. Remove
MyMethodInterceptor; AutoProxyCreation still occurs for foo and bar
beans without it.
Copy AbstractAutowireCapableBeanFactory locally
Unwrap proxies in AbstractAutowireCapableBeanFactory

Quick and dirty to prove the approach. Won't fly for real because use of
Advised interface introduces a cycle between spring-beans and spring-aop.

All tests pass.
Introduce unwrapAopProxyIfNecessary util method

For reasons mentioned in the previous commit, detecting/unwrapping AOP
proxies within AbstractAutowireCapableBeanFactory is not feasible. The
work here rather needs to be done by the client.

The idea is simply to use AopUtils to detect and unwrap the target of
an AOP proxy *before* calling beanFactory.autowireBeanProperties(...),
and this commit demonstrates how to do so.

Note that use of #autowireBeanProperties, #configureBean and other
similar methods are primarily designed for use by third-party
integrators as opposed to everyday Spring developers. For this reason
it's justifiable to require a little more effort to get things working.
added SPR-8824
SPR-8658