[jbossws-dev] [JBWS-CXF] On injections and @PostConstruct

[Sergey Beryozkin]

Hi Alessio
> >   
> >> Hi Sergey,
> >>
> >> Sergey Beryozkin wrote:
> >>     
> >>> By the way as far as the PostConstruct in Spring is concerned, I 
> >>> reckon the only way is to tell Spring not to call @PostConstruct.
> >>>       
> >> This 
> >>     
> >>> is because JBossCXF level injection won't work even if we find a
> way
> >>>       
> >>> to do the injection just before Spring calls PostConstruct because
> 
> >>> JBoss JNDI context is not ready at a time when Spring does the 
> >>> initialization - lets chat at IRC tomorrow
> >>>       
> >> Afaics today with a quick debug, currently the spring support for 
> >> resource injection and @PostConstruct invocation is disabled by
> >> default. 
> >> That can be enabled by un-commenting the following in cxf.xml / 
> >> jbossws-cxf.xml:
> >>
> >> <!--  For Testing using the Swing commons processor, uncomment one
> >> of:
> >>     <bean 
> >>
> class="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor"/>
> >>     <context:annotation-config/>
> >>     -->
> >>
> >> as a matter of facts, the JSR250BeanPostProcessor that cxf installs
> 
> >> correctly find out spring is not handling the injections and
> enables
> >> itself.
> >> In any case, the @PostConstruct invocation on the endpoint bean
> seems
> >> to 
> >> be explicitly requested by cxf code in the 
> >> JaxWsServerFactoryBean::injectResources(Object instance). A new 
> >> ResourceInjector is created there and used.
> >> While we could probably provide our factory redefining that 
> >> injectResources method [1] (otherwise we also do double injection
> for
> >>
> >> all the handlers too...), 
> >>     
> >
> > I'm not sure the double injection is an issue given that a Spring
> context may have the properties
> > available which would not be available to JBoss InjectionHelper.
> >   
> Right, I didn't think about this.
> 
> > While working on the tests I saw Spring complaining it could not
> inject some EJB-related resources, etc.
> > But a bit later JBoss InjectionHelper completed the job...
> >
> >   
> Good
> >> there's still the problem of the ejb3 jndi 
> >> context not being available at that time.
> >> I think this is something that changed recently, see 
> >> http://community.jboss.org/message/533419#533419 and 
> >> https://jira.jboss.org/browse/JBWS-2970 . The workaround that I 
> >> suggested and Richard implemented was to actually use the context
> at 
> >> runtime only, because with Native stack that was an easy and
> >> completely 
> >> valid solution (an instance of the pojo endpoint bean is actually 
> >> created at runtime only). With the CXF stack we might want to
> consider
> >>
> >> going back and evaluating what Carlo proposed on the forum, that's
> 
> >> making sure the context is available when the deployment aspect for
> 
> >> injections metadata is run.
> >>     
> >
> > This would still likely result in a double injection...Because the
> InjectionHelper is not aware of some of the context properties 
> >
> >   
> >> Otherwise the workaround is still to actually prevent any resource
> 
> >> injection / jsr250 invocation by the cxf serverfactorybean and do
> that
> >>
> >> in the servlethelper as you did (we should check if postponing all
> the
> >>
> >> endpoint/handlers resource injection there has some effects on cxf
> 
> >> bus/model creation - but I don't think there're problems here).
> >>     
> >
> > I'd only consider postponing @PostConstruct, but a  more complete
> solution could be indeed providing a custom ResourceInjector
> > as you suggested...
> >
> >   
> OK. Being able to provide a custom resource injector would also be a
> way 
> for postponing the @PostConstruct invocation in an clean way, without
> 
> the need for re-defining the server factory bean.


I'll investigate and see what can be done at the CXF level


thanks, Sergey


> 
> Cheers
> Alessio
> 
> -- 
> Alessio Soldano
> Web Service Lead, JBoss