I'm not quite sure if I understand your question. I suspect that this relates to this area of the web.xml:
See also RMH Page 666 and Figure 22-6. That element says
servlet but it is actually configuring the endpoint BookQuoteJSE running inside a JAX-RPC Servlet, it isn't configuring the JAX-RPC servlet itself. It simply uses the existing mechanism for naming the endpoint so that it can be referenced with servlet-link or port-component-link descriptors. This (servlet-link) name is used by the webservice.xml to reference deployment information that is specific to a JSE, just like a (ejb-link) name is used to reference info specific to an
EJB endpoint (RMH 699; Listing 23-5).
These "link" descriptors are of particular interest to platform vendors who might offer optimizations where clients of a web service that are deployed on the same application server as the web service itself, can bypass the conversion to HTTP (and possibly SOA). These optimizations would bypass filters anyway (and would possibly bypass even the JAX-RPC handlers).
Point: The servlet descriptor configures the JSE not the JAX-RPC Servlet.
Now RMH 669; Table 22-1 seems to indicate that filters can effectively see the HTTP request, responses for JSEs.
Contemplating on the context of my experiments I now seem to recall that the web service in question was in fact an EJB endpoint. Basically if you needed access to the raw HTTP request (at the time my intent was to grab the requestor's IP address and stuff it in a SOAP header to make it available to the JAX-RPC handlers) then you are limited to a JSE. It seemed that the EJB container was doing its own "HTTP thing" - ignoring the already existing capabilities in the web container.
In conclusion: I would guess that for a JSE a filter
can see the JSE's HTTP requests and responses � however the filter
will not see any of the HTTP requests and responses for any EJB endpoint in the same J2EE application.