Registering Listeners in web.xml

[Paul Statham]

In HFSJ they use an registering an ServletContextListener as their example in web.xml, which is something like this

<servlet>
   ...
</servlet>
<listener>
   <listener-class>
      com.example.MyServletContextListener
   </listener-class>
</listener>

With the comment that the <listener> element does not go inside the <servlet> element because a context listener is for the context not for a specific servlet. So my question is, what about a ServletRequestListener say? That can be specific to a servlet, in that example would <listener> appear inside <servlet>, or is it always outside <servlet>?

[Frits Walraven]

So my question is, what about a ServletRequestListener say? That can be specific to a servlet, in that example would <listener> appear inside <servlet>, or is it always outside <servlet>?

Listeners (i.e. all type of listeners) are always registered outside <servlet>.

Regards,
Frits

[Stoian Azarov]

If you want to create listener that is specific for a servlet you have to use some kind of workaround. As Frist already pointed you cannot declare <listener> inside <servlet> tag.
If your goal is to run the listener for every request that is forwarded to specific listenr you can use filtration code something like this.

public class MyRequestListener implements ServletRequestListener {
    public void requestInitialized(ServletRequestEvent event) {
        ServletRequest request = event.getServletRequest();
        if (request instanceof HttpServletRequest) {
             ((HttpServletRequest) request).getServletPath().equalsIgnoreCase("...servlet path here...");
             //your code here
        }
    }
    
    public void requestDestroyed(ServletRequestEvent event) {}
}

Of course, this won't be a smart solution because you are hardcoding the servlet path into the listener code and once the servlet <url-pattern> changes in web.xml the code won't work. And the performance will suffer because this listener will be called for every request in the web application.
Because of that, it might be better in this case to use a filter, that is mapped to the servlet's url pattern. That way you will keep the configuration in the DD and it will be easier to make changes.
Yet another possibility is to put your code into servlet's init() method(if the code should be executed only once when servlet is initialized) or in service() or one of the doXXX() methods. Keep in mind that if you override service() method you've better call the overriden version with super.service()

HTH