SERVLET_SPEC-79, was: SCI discovery ordering

[Jeremy Boynes <jb...@apache.org>]

On Sep 20, 2013, at 2:43 PM, Nick Williams <ni...@nicholaswilliams.net> wrote:

> 
> 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.

I think that's a good option when all SCIs are in named web fragments. However, there are two cases it does not cover:
1) when the SCI is declared in an anonymous web fragment (a jar in WEB-INF/lib without an XML DD)
2) when the SCI is declared by the container

AIUI, the other containers name anonymous fragments using the basename of the jar, allowing them to be referenced in an ordering clause more specifically than as "others." Tomcat, however, uses the actual URL of the jar which is not known to the deployer. We would need to change our naming mechanism to allow that, and the spec would want to codify a way to reference anonymous fragments.

This still would not allow ordering to reference SCIs declared by the container as a portable application cannot reference such a container specific artifacts and so cannot include them in ordering.

Cheers
Jeremy