struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Spring BeanPostProcessor called twice for Struts managed beans
Date Thu, 15 Oct 2015 13:26:01 GMT
I could be mistaken, but that would only solve not invoking the post instantiation callbacks
on the bean and would also imply that the BeanPostProcessor implementations actually implement
the InstantiationAwareBeanPostProcessor interface I believe.   It also seems far more logical
to put this burn on the dependency injection framework itself, particularly since the framework
already manages this bean lifecycle workflow itself.  

-----Original Message-----
From: Martin Gainty [] 
Sent: Thursday, October 15, 2015 7:29 AM
To: Struts Users Mailing List <>
Subject: RE: Spring BeanPostProcessor called twice for Struts managed beans

> From:
> Date: Thu, 15 Oct 2015 07:56:24 +0200
> Subject: Re: Spring BeanPostProcessor called twice for Struts managed 
> beans
> To:
> You are probably right :) Please register an issue and target 2.3.25 
> as a fix version.
> Regards
> --
> Ɓukasz
> + 48 606 323 122
> 2015-10-15 6:57 GMT+02:00 CRANFORD, CHRIS <>:
> > 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, 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,
> >
> > Thanks,
> > Chris
MG>2 leads who preceeded Lukasz didnt test out the 
MG>alwaysRespectAutowireStrategy = false logic no testcase means bug 
MG>buried deep within code and  never shouldve seen light of day in a 
MG>Continous Integration environment all features have at least one 
MG> if juergens spring code detects property assignment on a 
MG>bean has already been set..maybe we can catch detect that
     * Perform operations after the bean has been instantiated, via a constructor or factory
     * 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
     * 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
     * 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:
> > For additional commands, e-mail:
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message