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

[Alessio Soldano]

Hi Sergey,

Sergey Beryozkin wrote:
> 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.

Cheers
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss