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 [mailto:mgai...@hotmail.com] Sent: Thursday, October 15, 2015 7:29 AM To: Struts Users Mailing List <user@struts.apache.org> Subject: RE: Spring BeanPostProcessor called twice for Struts managed beans > 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 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>testcase..so 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 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
