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 <[email protected]> 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 <[email protected]>:
>>> 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 <[email protected]
>>> >
>>> 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 <[email protected]>:
>>> >
>>> > > 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
>>> > >
>>> >
