> >> 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.

Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss