Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [servlet-dev] Rationale for assertion Servlet:JAVADOC:668.6

Hi, 

Nice find!

On Tue, Sep 8, 2020 at 10:54 PM Mark Thomas <markt@xxxxxxxxxx> wrote:
What I haven't been able track down is how/why the wording changed from
"ServletContextListeners from a TLD"
to
"ServletContextListener that is neither declared in web.xml or
web-fragment.xml, nor annotated with @WebListener"

I can only guess, but perhaps whoever wrote that just forgot about programmatically added ServletContextListener instances, being so focussed on TLDs?
 
I think it was to prevent programmatically added ServletContextListener
instances (added via ServletContainerInitializer.onStartup()) using the
Servlet 3.0 programmatic APIs but I don't immediately see the issue with
that.

Me neither. If there's no issue with programmatic really, but the entire restriction is just to prevent listeners from TLDs calling Servlet 3.0 methods, it really makes no sense.

Especially since I guess those restrictions won't ever be updated for Servlet 4, Servlet 5, Servlet 6, etc methods. Over time, it would be quite awkward if we have an ever growing collection of methods that need to throw exceptions, just based on whether they were added after Servlet 2.5, which will be nothing more than a distant memory.
 
My own take on all of this is that there is scope to relax the rules for
some of the methods but not all of them (assuming we wish to retain
backwards compatibility).

Which methods would still need to throw exceptions? I have to give it a little more thought, but atm I can't quite see anything that would cause major issues. Of course, if anything did a try/catch-ignore around adding say a Filter, that would have been a no-op before, and would after this change result in the filter being actually added. Is that what you mean?

Kind regards,
Arjan



 

Mark

>
> Kind regards,
> Arjan
>
>
>
> On Tue, Sep 8, 2020 at 3:00 PM Stuart Douglas <sdouglas@xxxxxxxxxx
> <mailto: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
>     <mailto: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 <mailto:servlet-dev@xxxxxxxxxxx>
>         To unsubscribe from this list, visit
>         https://www.eclipse.org/mailman/listinfo/servlet-dev
>
>     _______________________________________________
>     servlet-dev mailing list
>     servlet-dev@xxxxxxxxxxx <mailto: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
>

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

Back to the top