Re: [jbossws-dev] [JBWS-CXF] On injections and @PostConstruct
by Sergey Beryozkin
Hi Richard
thanks for the review. I actually started modifying the CXF code so that a custom ResourceInjector can be injected
but then I thought, given that ResourceInjector is a concrete class and its initialization is a bit involved too, we'd need
to have more complex requirements (compared to just blocking/postponing a PostConstruct call) for us to start overriding ResourceInjector. The code can be enhanced when needed...
cheers, Sergey
> Hi Sergey,
>
> I reviewed your patches on both CXF and JBoss side.
> IMO it's sufficient for now how you prototyped it ;)
>
> Rio
>
> On 07/08/2010 06:06 PM, Sergey Beryozkin wrote:
> > Hi
> >
> >
> >> After doing the initial investigation, it seems to me that
> introducing
> >> a 'blockPostConstruct' property into
> >> JaxWsServerFactoryBean can make the trick. Another update which is
> >> needed is adding a protected JAXWSServerFactoryBean getter to CXF
> >> EndpointImpl so that a JBoss CXF EmdpointImpl can set a
> >> blockPostConstruct property to true thus not requiring overriding
> >> JAXWSServerFactoryBean and injecting it into CXF EndpointImpl;
> >>
> > I attached a patch to the JBWS-3001 JIRA :
> https://jira.jboss.org/browse/JBWS-3001,
> > it can be applied once CXF 2.2.10 gets released, see
> http://svn.apache.org/viewvc?rev=961823&view=rev.
> > The framework JBWS-2068 test passes if JBossCXF depends on the
> modified CXF 2.2.10 snapshot.
> >
> >
> >
> >> I'll also enable the injection of a custom ResourceInjector
> >>
> >>
> > I actually stopped short of doing it - I though being able to
> disable calling a PostConstruct method by setting a property
> > might be simpler...The code may be further modified if we really
> need to be able to injected custom ResourceInjectors
> >
> > Let me know please if you have any doubts
> >
> >
> >> cheers, Sergey
> >>
> >>
> > _______________________________________________
> > jbossws-dev mailing list
> > jbossws-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbossws-dev
> >
>
>
> --
> Richard Opalka
> ropalka(a)redhat.com
> JBoss, by Red Hat
>
> Office: +420 222 365 200
> Mobile: +420 731 186 942
>
> _______________________________________________
> jbossws-dev mailing list
> jbossws-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbossws-dev
13 years, 10 months
Re: [jbossws-dev] [JBWS-CXF] On injections and @PostConstruct
by Sergey Beryozkin
Hi
>
> After doing the initial investigation, it seems to me that introducing
> a 'blockPostConstruct' property into
> JaxWsServerFactoryBean can make the trick. Another update which is
> needed is adding a protected JAXWSServerFactoryBean getter to CXF
> EndpointImpl so that a JBoss CXF EmdpointImpl can set a
> blockPostConstruct property to true thus not requiring overriding
> JAXWSServerFactoryBean and injecting it into CXF EndpointImpl;
I attached a patch to the JBWS-3001 JIRA : https://jira.jboss.org/browse/JBWS-3001,
it can be applied once CXF 2.2.10 gets released, see http://svn.apache.org/viewvc?rev=961823&view=rev.
The framework JBWS-2068 test passes if JBossCXF depends on the modified CXF 2.2.10 snapshot.
>
> I'll also enable the injection of a custom ResourceInjector
>
I actually stopped short of doing it - I though being able to disable calling a PostConstruct method by setting a property
might be simpler...The code may be further modified if we really need to be able to injected custom ResourceInjectors
Let me know please if you have any doubts
> cheers, Sergey
>
13 years, 10 months
Re: [jbossws-dev] [JBWS-CXF] On injections and @PostConstruct
by Sergey Beryozkin
Hi
> > >
> > > 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
>
After doing the initial investigation, it seems to me that introducing a 'blockPostConstruct' property into
JaxWsServerFactoryBean can make the trick. Another update which is needed is adding a protected JAXWSServerFactoryBean getter to CXF EndpointImpl so that a JBoss CXF EmdpointImpl can set a blockPostConstruct property to true thus not requiring overriding JAXWSServerFactoryBean and injecting it into CXF EndpointImpl;
I'll also enable the injection of a custom ResourceInjector
cheers, Sergey
>
> thanks, Sergey
>
>
> >
> > Cheers
> > Alessio
> >
> > --
> > Alessio Soldano
> > Web Service Lead, JBoss
>
>
> _______________________________________________
> jbossws-dev mailing list
> jbossws-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbossws-dev
13 years, 10 months
Re: [jbossws-dev] [JBWS-CXF] On injections and @PostConstruct
by 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.
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...
>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...
> 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
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
13 years, 10 months
[JBWS-CXF] On injections and @PostConstruct
by Alessio Soldano
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
--
Alessio Soldano
Web Service Lead, JBoss
13 years, 10 months