问题
The front-controller was a Servlet but in Struts2, it is a filter. What is the possible reason to change it to a filter?
回答1:
(This is opinion, you'd need to ask the original WebWork authors.)
IMO it's a bit more intuitive to wrap requests inside a filter, since that's what filters were designed for.
There has been debate about the validity of serving resources from a filter. The spec states:
Filters do not generally create a response or respond to a request as servlets do, rather they modify or adapt the requests for a resource, and modify or adapt responses from a resource.
Some have claimed (particularly some WebSphere support tickets, and occasionally myself before re-reading the spec during an email thread on the Struts User mailing list) that the spec disallowed Struts 2's filter usage, but it's clear that nothing disallows their usage in this way.
Filters allow more flexibility in handling other types of requests (forwards, includes, and container errors) by using the <dispatch> element under <filter> configuration.
Note that originally it was a servlet in WebWork--you may be able to look at the commit logs to ferret out a reason whenever it was the change occurred, but it was quite awhile ago, on the order of 7+ years.
回答2:
Because of the introducing Interceptors in struts2. It becomes necessary for Struts2 contributors to have main controllers from the front so that a user can not breach a threat within the Java EE pattern. However Struts2 dispatchers are built on the top of the hierarchy of the servlet but it reduces a lot effort from the security point of view.
Reasons:
- Provide a centralized controller to a framework.
- To have interceptors and context which can dance on your fingers.
回答3:
There are three possibilities why filter is designated as front controller in Strtus2
Servlet made as front controller needs developer to provide a right value in which lets the framework to initialize many important aspects( viz. struts configuration file)as the container starts. In absence of which the framework gets initialized only as the first request hits.Struts2 makes our life easy by providing front-controller as a filter and by nature the filters in web.xml gets initialized automatically as the container starts. There is no need of such load-on-startup tag.
The second but important one is, the introduction of Interceptors in Struts2 framework. It not just reduce our coding effort, but helps us write any code which we would have used filters for coding and necessary change in the web.xml as opposed to Struts1.So now any code that fits better in Filter can now moved to interceptors (which is more controllable than filters), all configuration can be controlled in struts.xml file, no need to touch the web.xml file.
The front controller being a filter also helps towards the new feature of Struts ie UI Themes. All the static resources in the Themes now served through the filter
来源：https://stackoverflow.com/questions/10582155/why-in-struts1-there-is-servlet-where-as-in-case-of-struts2-there-is-filter