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. 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. 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. -- Jeremy
signature.asc
Description: Message signed with OpenPGP using GPGMail
