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