On Tue, Sep 2, 2008 at 8:20 AM, Costin Manolache <[EMAIL PROTECTED]> wrote: > On Tue, Sep 2, 2008 at 3:57 AM, Tim Funk <[EMAIL PROTECTED]> wrote: > >> Costin Manolache wrote: >> >>> <A LOT OF STUFF WHICH CAN BE FOUND IN THE ARCHIVES> >> >> Cool. In a nutshell - I like all the ideas. >> >> But while I like the idea of ditching Valves/LifecycleListeners - how does >> this work when the component needs to work across multiple ServletContext's? >> The only reason I see that Valves/LifecycleListeners need to yet exist is to >> handle those kind of issues. Examples: AccessLogValve or any Valve which >> needs to act on an the entire Container or a single virtual host. > > Using Filter interface doesn't mean we need to restrict it to a single > ServletContext or not have access to internal objects, > it should be possible to set them at container level. In tomcat-lite I tried > either using the ROOT context, or using a super-context > that comes before root - the filter chain in this context will replace the > existing catalina valve chain. > > There is also a package - java/o.a.tomcat.servlets.addon ( like everything > else in tomcat-lite, name and interfaces are subject to review and > change ) with an attempt to abstract common interfaces that a filter could > use to get extra-access to the container internals. > The interfaces can be implemented by catalina, the new tomcat-lite - and > maybe other containers if the choose so. > Ideally, an extension will check if the container supports the extra > interfaces and if not degrade to single-context mode if not. > > Costin
I also like seeing discussion around new ideas for improving Tomcat, and I agree that a minimalistic Tomcat jar distribution could strike a chord with many developers who otherwise use a different servlet container since Tomcat doesn't offer that. Thanks for your work on it! I think one important feature would be the availability of a Tomcat jar, and docs that show how to embed it in a standalone Java application. Even if that was available and the size of the jar was still rather large, people would still use it, I think. Hard disk capacities are getting quite large, machines are getting faster at moving bits around, and having all of Tomcat's regular features and compatibility packaged as a jar file would be worth it. If it could be possible to make the jar file smaller (by offering build-time subsetting maybe? with popular subset jars up for download?), while still maintaining a high degree of compatibility with the full Tomcat distribution, that would be even better. About Valves versus Filters.. I don't see the advantages of using Filters in the container instead of Valves. Here are some reasons I've heard for either completely removing Valves, or for using something else instead of Valves, and my thoughts on each: Reason 1: Valves complicate the container, and are a layer that can be removed. I don't agree that it can just be removed and nothing added right back to replace it. You're talking about replacing Valves with Filters, so no layer would be removed in that case. The feature like Valves is useful, which is why you're suggesting Filters as a replacement. If Tomcat lite's embedding code had a runtime configuration feature for turning off Valves, that would allow a developer to choose to have it as part of the request processing or not (though doing that wouldn't make the Tomcat jar any smaller). Still, if you want Filters where Valves currently are, then you probably wouldn't the binary significantly smaller doing that. Reason 2: Valves are Tomcat-specific and are not cross-container like Filters, so if we used Filters then developers on other servlet containers could also develop and use the Filters. Web container-space code is intentionally not specified in the Servlet Specification, maybe to promote creativity and flexibility in the implementation of web containers. This is a zone where servlet container teams compete with one another, and try to offer value in the form of better capabilities or better performance. They can't offer a better servlet API. That part has to work like it does in all of the other servlet containers. So non-standardized features like Valves and different packaging/embedding models, additional useful configuration options, and better overall performance make people decide to use one servlet container over another. We could try to standardize more features that the Servlet spec does not attempt to standardize, but I think most people won't want to, partially for competitive reasons. We could attempt to adapt Filters to this job, which are already standardized, but their behavior is specified only for webapp-space use, and using Filters for container-space would confuse a lot of people. We would have to have two different kinds of filter mappings, one in web.xml and another in server.xml (right?). I also do favor the strong type differences between Valve and Filter. Right now, it's perfectly clear which is which, and what they're each used for (IMO). Reason 3: Valves are old, and Filters were made to replace them, so we don't need Valves anymore. Before most servlet containers had the feature of Filters, Tomcat already had Valves, and certainly more Valves were written back then because (at least with Tomcat) that was about the only way you could do it. Then, when Filters worked, many developers converted their Valves to Filters so that the code could be cross-container. Most Valves could just instead be made into Filters, so most Valve implementations became Filters. But, that's all webapp-space, single context. There are (admittedly more rare) cases where developers need to write multi-context Valves, and not modify the webapps in any way, or where developers need to write something that runs as part of the container system regardless of the number of contexts it's encapsulating. So, Valves do a job that Filters cannot, and webapp-space filters can't entirely replace Valves.. without running in the container space where they're not specified/standardized to run. If they're nonstandard that way, then how would that be different than Valves? The Filter interface is not Tomcat specific? Maybe the Valve interface should be changed so that it's not Tomcat specific. Or, maybe not, since changing the interface causes some incompatibility. Reason 4: Valves don't need to be Tomcat specific to filter requests, so they shouldn't be, and so we should use Filters instead because they're not Tomcat specific. This reason is about whether Valves should have dependencies on Tomcat internal classes, based on separation of concerns alone. It might be true that Valves wouldn't have to have any dependencies on Tomcat internal classes in order to perform request filtering, but this code is running in the container space anyway, and is actually more powerful if Valve code has full access to Tomcat internals, and runs as a first class container object. More features are available, even if they are Tomcat specific. Features that are not meant to be available to Filters. I think Filters and Valves are two different things (even if there are similarities), and should be two different types, and I think both of these features should be available in Tomcat, including Tomcat lite. Thanks. -- Jason Brittain --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
