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