On Sep 22, 2013, at 10:55 AM, Jeremy Boynes <jboy...@apache.org> 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. 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. Patch to avoid this by following classloader delegation order …
sci.patch
Description: Binary data
signature.asc
Description: Message signed with OpenPGP using GPGMail
