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