On Sep 19, 2013, at 11:32 AM, Jeremy Boynes wrote: > On Sep 19, 2013, at 8:36 AM, Mark Thomas <ma...@apache.org> wrote: > >> On 19/09/2013 16:31, Jeremy Boynes wrote: >>> On Sep 19, 2013, at 6:07 AM, ma...@apache.org wrote: >>> >>>> Author: markt Date: Thu Sep 19 13:07:02 2013 New Revision: >>>> 1524727 >>>> >>>> URL: http://svn.apache.org/r1524727 Log: Always load container >>>> SCIs first >>> >>> This seems at odds with the requirement that "the order in which >>> these services are discovered MUST follow the application’s class >>> loading delegation model" which is independent of orderedLibs. If >>> we base this on ServiceLoader, which seems to be the intent, the >>> algorithm would be: >> >> Nope. See the discussion on the users list. >> >> There is a clear need for container defined SCIs to be executed first >> and there is nothing (yet) in the Servlet spec that places any >> constraints on SCI execution order. > > There's a clear model already without assumptions about SCI ordering: SCIs > fire before SCLs, and SCLs can be ordered explicitly by web.xml. There are no > ordering requirements for SCIs except that they are discovered per the > delegation model. This change is changing that to load "container" SCIs > firsts *even if the delegation model specifies application first.*
Loading/discovering SCIs and invoking SCIs are not the same thing. This change is spec compliant because it still loads/discovers SCIs per the delegation model. The spec does NOT say that SCIs must be ordered according to the delegation model (or even that they must be ordered in any fashion at all). > > The original issue was that a context attribute was not set when an SCI was > run (or actually, as a application class invoked by Spring's SCI was run). As > Konstantin pointed out, there is no issue here if that code is run from an > SCL rather than the SCI. I argue this is an application issue rather than > something the container needs to enforce in a proprietary manner. It is > similar to JSP land where Jasper's SCI can only register TLD listener or JSP > servlet classes with the context rather than actually instantiating them. > > Further, running container SCIs first may interfere with application SCIs > that would be "discovered" first - for example, an application should be able > to provide an SCI that initialized a WebSocket or JSP implementation separate > from the container's and which, because it would be first in delegation > order, would take precedence over the container's. > > I agree 3.2 should clarify the ordering requirements for SCIs even if it just > explicitly states there are no ordering guarantees or that they will be fired > in the order discovered through the classloader. Until then though it should > be on applications to code defensively on the assumption they may be fired in > any order.
smime.p7s
Description: S/MIME cryptographic signature
