Hi Thai Le, to match spec requirements the jaxrs whiteboard registers one ServletContextHelper per JAX-RS application (unless you use aries proprietary extensions to reuse pre existing servlet context helpers) and then deploys CXF servlet in it. The servlet context helper carries the properties from the application service so, if you need to deploy some filters to the applications ServletContextHelper you should be able to do so targeting the servlet context helper with the same osgi.jaxrs.name as your application.
CXF servlet is registered to serve all requests that arrive to the application's path because that path is supposed to belong to the REST application. This does not prevent any javax filters to be executed before the servlet. You should be able to register the filters to specific URL patterns or directly to the CXF servlet. These filters are going to execute before CXF servlet. So the servlet url pattern should not prevent any filters to be executed, if it did it would be a bug in the HTTP Whiteboard implementation. Would this help? Carlos. El 23/4/19 a las 20:48, Nhut Thai Le escribió: > > Hello, > > We have been using aries-jaxrs-whiteboard to run our REST api along > with paxweb-extender-whiteboard for sometimes. Recently we upgraded > aries-jaxrs-whiteboard from version 1.0.1 to 1.0.4 and noticed that > some of our servlets/filters are not working anymore. Digging into the > servlet registration process, I found that in the new > aries-jaxrs-whiteboard, a cxf-servlet is registered with url pattern > /* which makes this servlet handles any request that does not match > the registered urlPattern without giving it a chance to match to > filter pattern. Is this a bug or i need to add some configuration to > prevent this cxf-servlet to handle unmatched request? > Attached is the screenshot showing the cxf-servlet being registered > with /* pattern. > > Thai Le
