Hey, Are you able to check my PR: https://github.com/apache/tomee/pull/304 <https://github.com/apache/tomee/pull/304>
And review the following test: https://github.com/apache/tomee/pull/304/commits/3f59d382b12ebc17b2d1fc9e587486d55fc4a749 <https://github.com/apache/tomee/pull/304/commits/3f59d382b12ebc17b2d1fc9e587486d55fc4a749> It creates a deployment with a servlet, a static file and a rest endpoint. All are reachable just fine. You can run it with: mvn -Pall-adapters clean test-compile surefire:test@test-tomee-remote-plume -Dtest=RestWithServletsTest The MP endpoints do not seem to interfere here. I might be missing something from your case… Thanks! Cheers, Roberto > On 31 Jan 2019, at 17:48, Roberto Cortez <radcor...@yahoo.com.INVALID> wrote: > > Ideally, we should reach an integration state such as MP is always available > without requiring additional configuration, but without interfering with the > current deployments. > > I agree that probably at this stage it would be safer to have some kind of > configuration to opt-in / opt-out, until we have a more stable environment. A > tricky thing is to find the right balance. Is it binary? It is either all or > nothing? Or do you have individual switches per spec? I see Config and Fault > Tolerance to be useful with little to none integration issues. The main > problems so far were always with the spec that change the web app in a way, > like health, openapi or metrics, which add additional endpoints. > > Regarding the CXFRSFilter, I am looking into it right now and I’ve made a > series of tests. The filter is only added when you have REST resources in the > app. I can confirm that servlets mapped in “/some_path” work just fine. The > ones on “/*" do not and I was about to test around the DefaultServlet. > > Look here: > https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L102-L136 > > <https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L102-L136> > > And here: > https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L82 > > <https://github.com/apache/tomee/blob/40105b482301461cf641d25529441333a2fa2778/tomee/tomee-jaxrs/src/main/java/org/apache/tomee/webservices/CXFJAXRSFilter.java#L82> > > It does try to find a servlet mapping that matches the request in the Tomcat > Wrapper and if it finds one, it just proceeds with the chain call (except for > /*). If you notice there is a special case for > org.apache.catalina.servlets.DefaultServlet, that I’m going to debug next. > > So, in theory, all mapped servlets except for /* and the default servlet > should execute properly. > > The /* is indeed problematic, since you don’t know what is in there and could > be effectively a rest endpoint. The only option I see is to do as you suggest > and to do the check the other way around, so check if the path is server by a > rest path and proceed with it and if not, just let it be handled by the > regular chain. It should be possible. > >> On 31 Jan 2019, at 16:56, j4fm <james.m...@my-managed.net> wrote: >> >> So I was thinking on this: >> >> 1. It would be ideal to be able to configure if MP endpoints/filters are >> enabled/disabled by default and then enabled/disabled per-context (i.e. >> opt-out vs opt-in behaviour). In TomEE MicroProfile edition, I expect it >> would be enabled by default. In Plus/Plume, I expect it would be disabled >> by default and enabled per-webapp. >> >> 2. With only 1. it would be a shame to not be able to make use of MP on >> existing webapps. I was thinking on possible options for resolving the >> CXF/JAX-RS issue and had some ideas. >> a. Not sure if possible, but if JAXRSInInterceptor could not raise a 404 >> exception and instead return to pass down the filter chain it could work. >> b. The CXFRSFilter could do the same endpoint checks that >> JAXRSInInterceptor does and avoid calling it in the first place for non-REST >> paths. >> c. CXFRSFilter could read an "exclude paths" filter configuration for >> contexts to consider as not REST. >> d. CXFRSFilter could check for an attribute set by a previous filter to >> indicate not to process as a REST resource. >> >> Not sure if you had something else in mind. Let me know if I should raise a >> ticket or can test something out. >> >> >> >> -- >> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html >
