On Sep 20, 2013, at 4:33 PM, Jeremy Boynes wrote: > On Fri, Sep 20, 2013 at 8:50 AM, Mark Thomas <ma...@apache.org> wrote: > >> On 20/09/2013 16:02, Jeremy Boynes wrote: >>> The only ordering concern for SCIs in the spec is that they are >>> "discovered" following the classloader delegation model. This will >>> typically be configured to load application classes first, >>> something r1524727 does not do. >> >> The intention of the language around discovery is to clarify the >> expected behaviour when both the container and the application provide >> an implementation of the same SCI. As with any other class, the >> delegation model adopted by the application must be used. >> >> It has no bearing on the order in which one SCI implementation is >> loaded with respect to another SCI. >> >> It has no bearing on the order in which one SCI implementation is >> invoked with respect to another SCI. >> >> r1524727 is fully compliant with the Servlet spec. > > > Thanks for clarifying. It still leaves the issue related to ordering and > also to duplicate functionality. > > For example, if both the application and the container use an SCI to > bootstrap JAX-WS functionality, which should be used? The deployer can > exclude the implementation in the application (using absolute ordering) but > she cannot make that usable in preference to the one in the container > unless they happen use the same implementation and SCI class. There is no > mechanism to exclude the implementation provided by the container and use > an equivalent but different mechanism included in the application. > > The SCIs we use (JSP and WS) are independent and can be called in any > order. The same is true of Spring's SCI itself. What triggered this issue > is application code being called by Spring's SCI that adds an implicit > coupling to WS, whereas WS says the application should be using a listener. > > To date, there is no presumption of ordering of SCI invocation in the spec > and so frameworks need to code defensively. I agree this is a burden on the > framework and limits the deployer's flexibility. To address that I'm saying > we need a more sophisticated mechanism for ordering/excluding SCIs akin to > (but separate from) that used for ordering fragments. Do you see any issue > with such a mechanism?
https://java.net/jira/browse/SERVLET_SPEC-79 My proposal in that issue, which I stand by, is to use web-fragment ordering for SCI ordering. Importantly, this supports ordering without changing the API or XML schema, so Servlet 3.0 and 3.1 can be *encouraged* to implement SCI ordering retroactively. I've already convinced the Jetty team to take the same approach Tomcat is taking. JBoss, WebLogic, and WebSphere already use web-fragment ordering. N
smime.p7s
Description: S/MIME cryptographic signature
