You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "John D. Ament" <jo...@apache.org> on 2018/01/14 13:36:29 UTC
Avoiding the use of PerRequestResourceProvider in CDI classes
Hi
I noticed that CXF requires a default constructor, even when it delegates
down to a CDI container to do the work. This is because all of the
resources/providers are passed to ResourceUtils.createApplication which in
turn creates the default PerRequestResourceProvider for those resource
classes.
When I create a dependent scoped CDI bean, I would expect I don't need a
default constructor, but right now its required. I think we could create a
replacement if we passed the List<ResourceProvider> to
the JAXRSServerFactoryBean being created, instead of letting the default
version be created first.
John
Re: Avoiding the use of PerRequestResourceProvider in CDI classes
Posted by Andriy Redko <dr...@gmail.com>.
Hey John,
Right, the issue comes from the fact that PerRequestResourceProvider does not understand the @Inject. That is why
it fails, it cannot find the constructor it could make use of. Nonetheless, your initial concern is valid and we
should look at the problem in a wider context. Thanks.
Best Regards,
Andriy Redko
JDA> Andriy,
JDA> Maybe it could do that in a prior state, but presently if there is no no-args constructor it throws an exception
JDA> ->
JDA> https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/lifecycle/PerRequestResourceProvider.java#L51-L54
JDA> Hence why this is an issue. Take a look at the BookStore class in CDI Systests to see my work around, even though the @Inject constructor should be the one used.
JDA> John
JDA> On Sun, Jan 14, 2018 at 12:53 PM Andriy Redko <dr...@gmail.com> wrote:
JDA> It makes a lot of sense to have the intantiation mechanism aligned with the
JDA> dependency injection framework being used. Right now it is CXF-driven in most
JDA> cases (static method calls, which translate to one of the newInstance() calls).
JDA> IMFO PerRequestResourceProvider does not actually require to have a default (noarg?)
JDA> constructor, it is able to call one with (injectable) arguments as well.
JDA> Best Regards,
JDA> Andriy Redko
RMB>> My thinking was to move it to the provider itself since you can mix a CDI
RMB>> (multiple scopes)/Spring/Custom set of providers in the same app with
RMB>> different constraints.
RMB>> Romain Manni-Bucau
RMB>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
RMB>> <https://rmannibucau.metawerx.net/> | Old Blog
RMB>> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
RMB>> LinkedIn <https://www.linkedin.com/in/rmannibucau>
RMB>> 2018-01-14 16:43 GMT+01:00 John D. Ament <jo...@apache.org>:
>>> So you're thinking along the lines of moving some of these features into an
>>> instance method on JAXRSServerFactoryBean so that implementors can
>>> extend/override the behavior?
>>> One thing I just noticed, this problem only happens when you have a JAX-RS
>>> Application that declares getClasses().
>>> John
>>> On Sun, Jan 14, 2018 at 10:08 AM Romain Manni-Bucau <rmannibucau@gmail.com
>>> >
>>> wrote:
>>> > +1, basically it leads to delegate all the bean validation (not the spec)
>>> > to the impl and skip the static utilities. This should probably be a
>>> > general rule in CXF: never use a static method, it prevents to do a lot
>>> of
>>> > things (like support meta annotation for jaxrs annotations for instance
>>> to
>>> > cite only another feature current design locks).
>>> >
>>> >
>>> > Romain Manni-Bucau
>>> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> > <https://rmannibucau.metawerx.net/> | Old Blog
>>> > <http://rmannibucau.wordpress.com> | Github <
>>> > https://github.com/rmannibucau> |
>>> > LinkedIn <https://www.linkedin.com/in/rmannibucau>
>>> >
>>> > 2018-01-14 14:36 GMT+01:00 John D. Ament <jo...@apache.org>:
>>> >
>>> > > Hi
>>> > >
>>> > > I noticed that CXF requires a default constructor, even when it
>>> delegates
>>> > > down to a CDI container to do the work. This is because all of the
>>> > > resources/providers are passed to ResourceUtils.createApplication
>>> which
>>> > in
>>> > > turn creates the default PerRequestResourceProvider for those resource
>>> > > classes.
>>> > >
>>> > > When I create a dependent scoped CDI bean, I would expect I don't need
>>> a
>>> > > default constructor, but right now its required. I think we could
>>> > create a
>>> > > replacement if we passed the List<ResourceProvider> to
>>> > > the JAXRSServerFactoryBean being created, instead of letting the
>>> default
>>> > > version be created first.
>>> > >
>>> > > John
>>> > >
>>> >
Re: Avoiding the use of PerRequestResourceProvider in CDI classes
Posted by "John D. Ament" <jo...@apache.org>.
Andriy,
Maybe it could do that in a prior state, but presently if there is no
no-args constructor it throws an exception ->
https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/lifecycle/PerRequestResourceProvider.java#L51-L54
Hence why this is an issue. Take a look at the BookStore class in CDI
Systests to see my work around, even though the @Inject constructor should
be the one used.
John
On Sun, Jan 14, 2018 at 12:53 PM Andriy Redko <dr...@gmail.com> wrote:
> It makes a lot of sense to have the intantiation mechanism aligned with the
> dependency injection framework being used. Right now it is CXF-driven in
> most
> cases (static method calls, which translate to one of the newInstance()
> calls).
>
> IMFO PerRequestResourceProvider does not actually require to have a
> default (noarg?)
> constructor, it is able to call one with (injectable) arguments as well.
>
> Best Regards,
> Andriy Redko
>
> RMB> My thinking was to move it to the provider itself since you can mix a
> CDI
> RMB> (multiple scopes)/Spring/Custom set of providers in the same app with
> RMB> different constraints.
>
>
> RMB> Romain Manni-Bucau
> RMB> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> RMB> <https://rmannibucau.metawerx.net/> | Old Blog
> RMB> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau>
>
> RMB> 2018-01-14 16:43 GMT+01:00 John D. Ament <jo...@apache.org>:
>
> >> So you're thinking along the lines of moving some of these features
> into an
> >> instance method on JAXRSServerFactoryBean so that implementors can
> >> extend/override the behavior?
>
> >> One thing I just noticed, this problem only happens when you have a
> JAX-RS
> >> Application that declares getClasses().
>
> >> John
>
> >> On Sun, Jan 14, 2018 at 10:08 AM Romain Manni-Bucau <
> rmannibucau@gmail.com
> >> >
> >> wrote:
>
> >> > +1, basically it leads to delegate all the bean validation (not the
> spec)
> >> > to the impl and skip the static utilities. This should probably be a
> >> > general rule in CXF: never use a static method, it prevents to do a
> lot
> >> of
> >> > things (like support meta annotation for jaxrs annotations for
> instance
> >> to
> >> > cite only another feature current design locks).
> >> >
> >> >
> >> > Romain Manni-Bucau
> >> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> >> > <https://rmannibucau.metawerx.net/> | Old Blog
> >> > <http://rmannibucau.wordpress.com> | Github <
> >> > https://github.com/rmannibucau> |
> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau>
> >> >
> >> > 2018-01-14 14:36 GMT+01:00 John D. Ament <jo...@apache.org>:
> >> >
> >> > > Hi
> >> > >
> >> > > I noticed that CXF requires a default constructor, even when it
> >> delegates
> >> > > down to a CDI container to do the work. This is because all of the
> >> > > resources/providers are passed to ResourceUtils.createApplication
> >> which
> >> > in
> >> > > turn creates the default PerRequestResourceProvider for those
> resource
> >> > > classes.
> >> > >
> >> > > When I create a dependent scoped CDI bean, I would expect I don't
> need
> >> a
> >> > > default constructor, but right now its required. I think we could
> >> > create a
> >> > > replacement if we passed the List<ResourceProvider> to
> >> > > the JAXRSServerFactoryBean being created, instead of letting the
> >> default
> >> > > version be created first.
> >> > >
> >> > > John
> >> > >
> >> >
>
>
>
Re: Avoiding the use of PerRequestResourceProvider in CDI classes
Posted by Andriy Redko <dr...@gmail.com>.
It makes a lot of sense to have the intantiation mechanism aligned with the
dependency injection framework being used. Right now it is CXF-driven in most
cases (static method calls, which translate to one of the newInstance() calls).
IMFO PerRequestResourceProvider does not actually require to have a default (noarg?)
constructor, it is able to call one with (injectable) arguments as well.
Best Regards,
Andriy Redko
RMB> My thinking was to move it to the provider itself since you can mix a CDI
RMB> (multiple scopes)/Spring/Custom set of providers in the same app with
RMB> different constraints.
RMB> Romain Manni-Bucau
RMB> @rmannibucau <https://twitter.com/rmannibucau> | Blog
RMB> <https://rmannibucau.metawerx.net/> | Old Blog
RMB> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
RMB> LinkedIn <https://www.linkedin.com/in/rmannibucau>
RMB> 2018-01-14 16:43 GMT+01:00 John D. Ament <jo...@apache.org>:
>> So you're thinking along the lines of moving some of these features into an
>> instance method on JAXRSServerFactoryBean so that implementors can
>> extend/override the behavior?
>> One thing I just noticed, this problem only happens when you have a JAX-RS
>> Application that declares getClasses().
>> John
>> On Sun, Jan 14, 2018 at 10:08 AM Romain Manni-Bucau <rmannibucau@gmail.com
>> >
>> wrote:
>> > +1, basically it leads to delegate all the bean validation (not the spec)
>> > to the impl and skip the static utilities. This should probably be a
>> > general rule in CXF: never use a static method, it prevents to do a lot
>> of
>> > things (like support meta annotation for jaxrs annotations for instance
>> to
>> > cite only another feature current design locks).
>> >
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > <https://rmannibucau.metawerx.net/> | Old Blog
>> > <http://rmannibucau.wordpress.com> | Github <
>> > https://github.com/rmannibucau> |
>> > LinkedIn <https://www.linkedin.com/in/rmannibucau>
>> >
>> > 2018-01-14 14:36 GMT+01:00 John D. Ament <jo...@apache.org>:
>> >
>> > > Hi
>> > >
>> > > I noticed that CXF requires a default constructor, even when it
>> delegates
>> > > down to a CDI container to do the work. This is because all of the
>> > > resources/providers are passed to ResourceUtils.createApplication
>> which
>> > in
>> > > turn creates the default PerRequestResourceProvider for those resource
>> > > classes.
>> > >
>> > > When I create a dependent scoped CDI bean, I would expect I don't need
>> a
>> > > default constructor, but right now its required. I think we could
>> > create a
>> > > replacement if we passed the List<ResourceProvider> to
>> > > the JAXRSServerFactoryBean being created, instead of letting the
>> default
>> > > version be created first.
>> > >
>> > > John
>> > >
>> >
Re: Avoiding the use of PerRequestResourceProvider in CDI classes
Posted by Romain Manni-Bucau <rm...@gmail.com>.
My thinking was to move it to the provider itself since you can mix a CDI
(multiple scopes)/Spring/Custom set of providers in the same app with
different constraints.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>
2018-01-14 16:43 GMT+01:00 John D. Ament <jo...@apache.org>:
> So you're thinking along the lines of moving some of these features into an
> instance method on JAXRSServerFactoryBean so that implementors can
> extend/override the behavior?
>
> One thing I just noticed, this problem only happens when you have a JAX-RS
> Application that declares getClasses().
>
> John
>
> On Sun, Jan 14, 2018 at 10:08 AM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > +1, basically it leads to delegate all the bean validation (not the spec)
> > to the impl and skip the static utilities. This should probably be a
> > general rule in CXF: never use a static method, it prevents to do a lot
> of
> > things (like support meta annotation for jaxrs annotations for instance
> to
> > cite only another feature current design locks).
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau>
> >
> > 2018-01-14 14:36 GMT+01:00 John D. Ament <jo...@apache.org>:
> >
> > > Hi
> > >
> > > I noticed that CXF requires a default constructor, even when it
> delegates
> > > down to a CDI container to do the work. This is because all of the
> > > resources/providers are passed to ResourceUtils.createApplication
> which
> > in
> > > turn creates the default PerRequestResourceProvider for those resource
> > > classes.
> > >
> > > When I create a dependent scoped CDI bean, I would expect I don't need
> a
> > > default constructor, but right now its required. I think we could
> > create a
> > > replacement if we passed the List<ResourceProvider> to
> > > the JAXRSServerFactoryBean being created, instead of letting the
> default
> > > version be created first.
> > >
> > > John
> > >
> >
>
Re: Avoiding the use of PerRequestResourceProvider in CDI classes
Posted by "John D. Ament" <jo...@apache.org>.
So you're thinking along the lines of moving some of these features into an
instance method on JAXRSServerFactoryBean so that implementors can
extend/override the behavior?
One thing I just noticed, this problem only happens when you have a JAX-RS
Application that declares getClasses().
John
On Sun, Jan 14, 2018 at 10:08 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> +1, basically it leads to delegate all the bean validation (not the spec)
> to the impl and skip the static utilities. This should probably be a
> general rule in CXF: never use a static method, it prevents to do a lot of
> things (like support meta annotation for jaxrs annotations for instance to
> cite only another feature current design locks).
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau>
>
> 2018-01-14 14:36 GMT+01:00 John D. Ament <jo...@apache.org>:
>
> > Hi
> >
> > I noticed that CXF requires a default constructor, even when it delegates
> > down to a CDI container to do the work. This is because all of the
> > resources/providers are passed to ResourceUtils.createApplication which
> in
> > turn creates the default PerRequestResourceProvider for those resource
> > classes.
> >
> > When I create a dependent scoped CDI bean, I would expect I don't need a
> > default constructor, but right now its required. I think we could
> create a
> > replacement if we passed the List<ResourceProvider> to
> > the JAXRSServerFactoryBean being created, instead of letting the default
> > version be created first.
> >
> > John
> >
>
Re: Avoiding the use of PerRequestResourceProvider in CDI classes
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1, basically it leads to delegate all the bean validation (not the spec)
to the impl and skip the static utilities. This should probably be a
general rule in CXF: never use a static method, it prevents to do a lot of
things (like support meta annotation for jaxrs annotations for instance to
cite only another feature current design locks).
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>
2018-01-14 14:36 GMT+01:00 John D. Ament <jo...@apache.org>:
> Hi
>
> I noticed that CXF requires a default constructor, even when it delegates
> down to a CDI container to do the work. This is because all of the
> resources/providers are passed to ResourceUtils.createApplication which in
> turn creates the default PerRequestResourceProvider for those resource
> classes.
>
> When I create a dependent scoped CDI bean, I would expect I don't need a
> default constructor, but right now its required. I think we could create a
> replacement if we passed the List<ResourceProvider> to
> the JAXRSServerFactoryBean being created, instead of letting the default
> version be created first.
>
> John
>