We have ATM a tomee "service" doing that and registering a filter for JAX-RS (to allow to serve plain web resources which was a common error of users). Having a CDI solution is not an option ATM since we have to work when CDI is not activated. We can surely check if we can merge more code but we actually have a light integration, the code mainly only create a server factory and read our specific configuration and then we delegate in the filter.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-09-23 15:41 GMT+02:00 Sergey Beryozkin <[email protected]>: > Hi Christian > > FYI, Andriy Redko contributed a lot and later John Ament contributed too > to the CXF CDI module - but it is very much JAX-RS centric right now. > Perhaps some of that code can be extracted to help a JAX-WS case too - we > talked awhile back about supporting both frontends > > Sergey > > > > > On 23/09/16 14:36, Christian Schneider wrote: > >> I also think is would be great to have the CDI support directly in cxf >> as a portable extension. It could then also be reused in pax-cdi for >> OSGi and also for standalone CDI cases. >> >> Christian >> >> On 23.09.2016 15:33, Sergey Beryozkin wrote: >> >>> Hi Romain >>> >>> What do you think of trying to utilize CXF CDI code for the purpose of >>> supporting CXF CDI services in TomEE ? >>> >>> You mentioned you had to hack ObjectHelper in TomEE so I guess CXF CDI >>> code 'missed out' :-). We have some CDI experts here on the list so >>> may be it can make sense... >>> >>> Thanks, Sergey >>> >> >> >> >
