Re: [servlet-dev] Rationale for assertion Servlet:JAVADOC:668.6

[arjan tijms <arjan.tijms@xxxxxxxxx>]

Hi,

We should definitely see if there's a reason for this artificial restriction, and if not, perhaps consider removing it?

There's variants that strike me as even more unclear, like:

  <assertion required="true" impl-spec="false" status="active" testable="true">

        <id>Servlet:JAVADOC:685.1</id>

        <description>if this ServletContext was passed to the ServletContextListener.contextInitialized(jakarta.servlet.ServletContextEvent) method of a ServletContextListener that was neither declared in web.xml or web-fragment.xml, nor annotated with WebListener</description>

        <package>jakarta.servlet</package>

        <class-interface>ServletContext</class-interface>

        <method name="getEffectiveMajorVersion" return-type="int">

            <throw>java.lang.UnsupportedOperationException</throw>

        </method>

    </assertion>

Why would that method need such restrictions?

Kind regards,

Arjan

On Tue, Sep 8, 2020 at 3:00 PM Stuart Douglas <sdouglas@xxxxxxxxxx> wrote:

This was not a problem for Undertow either, I had to add a heap of logic artificially restricting this to pass the TCK when these tests were added.

Stuart

On Tue, 8 Sep 2020 at 19:24, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

Hi,

The following assertion states than an UnsupportedOperationException must be thrown if addFilter is called on a ServletContext passed to a ServletContextListener that wasn't declared by either annotation or xml:

<assertion required="true" impl-spec="false" status="active" testable="true">

        <id>Servlet:JAVADOC:668.6</id>

        <description>if this ServletContext was passed to the ServletContextListener.contextInitialized(jakarta.servlet.ServletContextEvent) method of a ServletContextListener that was neither declared in web.xml or web-fragment.xml, nor annotated with WebListener</description>

        <package>jakarta.servlet</package>

        <class-interface>ServletContext</class-interface>

        <method name="addFilter" return-type="jakarta.servlet.FilterRegistration.FilterRegistration.Dynamic">

            <parameters>

                <parameter>java.lang.String</parameter>

                <parameter>java.lang.String</parameter>

            </parameters>

            <throw>java.lang.UnsupportedOperationException</throw>

        </method>

    </assertion>

I wonder what's the exact reason for this.

In Piranha for example listeners are added from container initializers quite universally and the web.xml and annotation ones add listeners in the same way as other container initializers would:

public void configure(WebApplication webApplication) {

        webApplication.addInitializer(new WebXmlInitializer());

        webApplication.addInitializer(new WebAnnotationInitializer());

        webApplication.addInitializer(new JakartaSecurityAllInitializer());

        webApplication.addInitializer(new ServletContainerAllInitializer());

 }

Making a distinction from listeners that have been added by (in this case) the WebXmlInitializer and say the ServletContainerAllInitializer is therefore quite artificial.

Now I appreciate that other containers might work differently, but I still wonder; is there really a need for this exception in other containers? I'm probably missing something and assume some potential ordering issue, but at the moment I don't quite see it.

Kind regards,

Arjan

_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev

_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev