On Thu, Sep 4, 2008 at 12:47 AM, Jason Brittain <[EMAIL PROTECTED]>wrote:
> 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. The 'lite' is more about complexity and layer reduction, size is just an extra benefit. I care more about the source size than the jar size - while disk is cheap, the time required to understand and maintain a large code is not. > > 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. You can see the code in sandbox/tomcat-lite - the code is currently not using Vavles, Listeners, server.xml, and many other things from catalina, just coyote and filters ( which are mostly refactored from original catalina valves ). That doesn't mean that Valves will dissapear - the plan is to add tomcat-lite engine as an alternative ( module ), but catalina will still be there and I don't plan to remove anything from it. Sure - replacing a Valve with a Filter in lite doesn't change the execution path. However it eliminates all the duplicated code for managing the valve pipeline, configuring valves, etc - we have to do it for Filter ( and in a certain way ), why have 2 times that ? I think the container code is also simpler and cleaner - again, you only have to understand and maintain Filters and filter chains ( very well documented and specified ). > > 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. That's probably the biggest reason I'm proposing Filters instead of Valves :-) The interaction between the Filters and container in tomcat-lite is specified in java/org/apache/tomcat/servlets/addon/, and the goal is to implement the same interfaces in catalina, and to be easy to implement them on top of other containers. If catalina auth, session management, logging Valves are refactored to Filters - they will be indeed usable in other containers and in tomcat-lite. Which is _great_ for everyone. > > 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. Competing with other containers is not one of tomcat goals AFAIK. Cooperating with other containers should be a goal for any open source container, because it helps our users. What's wrong if someone could take the session management or auth from tomcat and use it in another container ( or reverse ) ? > 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). Actually - server.xml will not be used in tomcat-lite ( but will remain in catalina, of course ). Yes, system filters ( that apply to the entire container ) will be in a separate config file, but will use the same syntax as web.xml ( another simplification for the user - why learn 2 config formats, reuse the tools, etc ). For some filters - it should be possible to use the same filter without any support from container, and configure it in the app web.xml. There are plenty of custom-auth filters already, logging filters, etc. > > > Reason 3: Valves are old, and Filters were made to replace them, so we > don't need Valves anymore. > 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. > Yes, the Filters will ( or can ) be used in a non-standard way - cross context, access to internal objects, etc. The only thing that will change in tomcat-lite is that all the code to deal with Valves will no longer be there. If other containers choose to support the 'addon' interfaces and similar model - the Filters could be reused, but it is not a goal to confine the new Filters to single context and user-space-only. > > 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. Same features will be available to (container-space) Filters, or if we choose so even to user-space filters ( i.e. configured in the app web.xml ). Unless you use the sandbox - user space code can access internal objects via reflection/introspection, if they want to. In tomcat-lite the sandbox is removed, and the 'addon' interfaces are available to all servlets and filters. Of course - any filter/servlet that uses the addon package will no longer be portable, will only work in tomcat-lite ( and catalina or other containers if addon support is added ). > > > 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. > Valves will obviously continue to be available to catalina. My proposal was just to add support for 'container-space filters' in catalina. A minimal set of 'container' Filters ( refactored from Valves ) already exists in tomcat-lite, it will be a choice for tomcat developers if they want to develop or refactor extensions as Valves ( specific to catalina ) or Filters ( work in both catalina and tomcat-lite, maybe other containers ). Tomcat-lite doesn't support Valves - again, the goal was to remove redundancy and complexity, if it has Valve - what's the point, we already have catalina. Costin > > Thanks. > > -- > Jason Brittain >
