> From: lukaszlen...@apache.org
> Date: Thu, 15 Oct 2015 07:56:24 +0200
> Subject: Re: Spring BeanPostProcessor called twice for Struts managed beans
> To: user@struts.apache.org
>
> You are probably right :) Please register an issue and target 2.3.25
> as a fix version.
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> 2015-10-15 6:57 GMT+02:00 CRANFORD, CHRIS <chris.cranf...@setech.com>:
> > In a recent BeanPostProcessor implementation, I noticed our logic was being
> > invoked twice in both the before and after initialization callbacks for
> > struts constructed objects like actions, interceptors, etc while normal
> > constructed Spring beans via component scanning were only being invoked
> > once.
> >
> > After debugging in 3.2.24.1, I narrowed the issue down to the
> > SpringObjectFactory implementation in Xwork2 at lines 194 to 197. It seems
> > XWork's implementation manually calls the before and after
> > BeanPostProcessor callbacks. Looking at the Spring source for
> > AbstractAutowireCapableBeanFactory, it seems initializeBean's
> > implementation also calls these callback methods too, which is what leads
> > to re-evaluating the struts constructed objects twice.
> >
> > I believe the plugin is based on Spring 3.0.5 (IIRC) and even reviewing the
> > code base at that release along with the latest 4.2.1 release, both confirm
> > that initializeBean has always invoked the BeanPostProcessor callbacks
> > internally and therefore, XWork's implementation really should not worry
> > with manually invoking them too.
> >
> > Is there a technical reason why the SpringObjectFactory is doing this or is
> > this an oversight?
> > This just seems like a significant overhead on bean management that could
> > be avoided, right?
> >
> > Thanks,
> > Chris
MG>2 leads who preceeded Lukasz didnt test out the
alwaysRespectAutowireStrategy = false logic
MG>no testcase means bug buried deep within code and never shouldve seen light
of day in a Continous Integration environment
MG>all features have at least one testcase..so
MG>if juergens spring code detects property assignment on a bean has already
been set..maybe we can catch detect that
/**
* Perform operations after the bean has been instantiated, via a
constructor or factory method,
* but before Spring property population (from explicit properties or
autowiring) occurs.
* <p>This is the ideal callback for performing field injection on the
given bean instance.
* See Spring's own {@link
org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor}
* for a typical example.
* @param bean the bean instance created, with properties not having been
set yet
* @param beanName the name of the bean
* @return {@code true} if properties should be set on the bean; {@code
false}
* if property population should be skipped. Normal implementations should
return {@code true}.
* Returning {@code false} will also prevent any subsequent
InstantiationAwareBeanPostProcessor
* instances being invoked on this bean instance.
* @throws org.springframework.beans.BeansException in case of errors
*/
boolean postProcessAfterInstantiation(Object bean, String beanName) throws
BeansException;
MG>Good Catch Chris!
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> > For additional commands, e-mail: user-h...@struts.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>
