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

[Richard Opalka]

See inlined comments

Rio

On 07/02/2010 09:51 AM, Alessio Soldano wrote:
> 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...), 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.
> 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).
> Cheers
> Alessio
>
> [1] or even modify that method @apache for allowing users to configure 
> the ResourceInjector to be used... giving us a clean hook for 
> installing our own injector
>
We have to do it properly so changes in CXF are necessary to make 
ResourceInjector configurable.
Also CXF can do the injection at runtime not in deploy time when EJB 
JNDI context is not available.

Rio

-- 
Richard Opalka
ropalka at redhat.com
JBoss, by Red Hat

Office: +420 222 365 200
Mobile: +420 731 186 942