On 22/09/2013 10:55, Jeremy Boynes wrote: > On Sep 22, 2013, at 1:44 AM, Mark Thomas <ma...@apache.org> wrote: > >> On 22/09/2013 00:27, Jeremy Boynes wrote: >> >>> As a concrete example of how this impacts the behaviour, consider >>> the case where the application includes its own JSP engine. With >>> the RI's delegation model, the application's engine's SCI would >>> execute first allowing it to register a Servlet and mapping to >>> handle the "*.jsp" pattern. When the container's engine's SCI was >>> executed, that mapping would already be bound and could not be >>> pre-empted (engines already need to allow for that in case the >>> application configured that mapping in its web.xml). If the >>> container is always given priority, then the container's engine >>> would be used rather than the one the application intended. >> >> No. It would still be loaded from the application (for that >> webapp). > > For two versions of the *same* implementation, yes.
Agreed. This is the case the EG was trying to cover. Unfortunately that is just a small part of the total grey area that could do with some clarification. > But if they used > *different* implementations of the *same functionality,* the > container's would always get precedence. For example, if an > application included Tyrus's WebSocket implementation it would always > be invoked after Tomcat's. Or for JAX-RS, if the container was > configured with CXF and the application included Jersey, Jersey would > not be able to register its Servlets for the REST endpoints as CXF > would have already mapped them. Some time ago, Tomcat allowed users to include container JARs in absolute orderings to handle this sort of situation. However, the EG was very clear that that behaviour was not permitted and that absolute ordering could only include applications JARs. I'm wondering if reverting to something like this might be the way to solve this. We shall see... > The issue here is that programmatic registrations cannot modify the > existing configuration. Once a framework has registered a servlet, > filter, listener or mapping it cannot be replaced by another. > Frameworks that applications bundle in WEB-INF/lib need to have a > chance to perform their initialization before an equivalent but > different implementation provided by the container. This is starting to get really messy. There are enough different edge cases that I'm not such I am keeping track of them all. I'm also not sure that SERVLET_SPEC-79 has captured them all either. Can I suggest the following approach: - start a new wiki page listing all the edge cases / problems / issues we can think of - discuss some solutions to those issues on list - more complex proposals can be documented on the wiki if necessary - document the proposal(s) on the wiki - update SERVLET_SPEC-79 with the full set of issues and solution(s) At that point we can figure out what minimal changes we can make to Tomcat 8 to align it as far as possible to the proposed solution. What I want to avoid is a large / invasive change to Tomcat to align it to the proposed solution only to have to undo / redo it if the EG opts for a different (or worse still no) solution. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
