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 > > >
