1 of 1 people found this helpful
I think that log message is a bug. What's happening here is that a deployment is considered a jaxrs deployment if it contains a jaxrs artifact/component. The implementation of the deployment processing logic attaches a marker to that deployment unit if it's a jaxrs deployment. However, the implementation also has a piece of logic which marks the *parent* (ear) deployment unit as a jaxrs deployment if _any_ of the child deployment units (war for example) has a jaxrs artifact wildfly/JaxrsDeploymentMarker.java at master · wildfly/wildfly · GitHub
So the deployment unit processors which rely on this marker to decide their rest of the logic, don't have a precise way for making that decision and the wildfly/JaxrsIntegrationProcessor.java at master · wildfly/wildfly · GitHub seems to be ending up in logging those messages against WAR sub deployment(s) which don't really have jaxrs artifacts.
You might want to raise a JIRA pointing back to this thread.
P.S: It's not just the logging which is a problem, but looking at the code, I think certain deployment processors might be doing additional work which they don't really need to do since the deployment isn't really a jaxrs one.
Frank, I believe  should fix this. If you can try the patch, feedback is welcome.
Jaikiran, thanks for the initial analysis. As for this being a more general bug, well... the whole jaxrs integration in the container might have to be revisited to properly avoid few processors from running when it's not really needed. The fact is that even if a war sub deployment does not have jaxrs annotated classes, it still has to be processed by the jaxrs processor for misc reasons, for example because its web metadata might include declaration of resteasy servlets.
So, for now I believe the proper action to take is to suppress the warning for sub-deployments.
Tried the fix and the Warnings no longer appear.