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(a)redhat.com
JBoss, by Red Hat
Office: +420 222 365 200
Mobile: +420 731 186 942