Quoting Vic Cekvenich <[EMAIL PROTECTED]>: > Craig R. McClanahan wrote: > > > > Regarding 2.x, an important consideration will be base technology platforms > -- > > I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 > (i.e. > > Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the > > presentation technology, etc.). > > > > > JDK 1.4, yes. > > One popular? goal mentioned was: > "Get away from reliance on Servlet API" > > I like being on Tomcat 4. > What does it gain to be Tomcat 5 technically?
For the portions of the framework that depend on Servlet 2.4, you get two modest but useful features: * Ability to execute filters on RequestDispatcher.include and RequestDispatcher.forward calls, which is not possible in 2.3. This gives you additional degrees of freedom in how you organize the processing logic of a framework like Struts -- for example, it would now be technically feasible to implement the controller as a filter instead of a servlet. * Ability to define request lifecycle listeners (like the older ones for session and application lifecycle) so you get a complete and consistent event handling model. If your presentation tier is based on JSP 2.0 (instead of 1.1/1.2), you get a very large number of benefits. The most visible ones are: * New ***much*** simpler API for building tag classes (tag instance pooling is gone, single invocation method instead of doStart/doEnd, ability to define a tag that takes an arbitrary list of attributes, ...). * Tag files -- essentially, the ability to write a tag handler using JSP code instead of Java, complete with parameter passing. * EL expressions evaluated everywhere (even template text), so you don't need to limit yourself to just tags that implement support for it (meaning we don't need struts-el variants). What containers support > 2.4? How long for users to convert to the new 2.4 containers? > It'd be limiting. > The timing only matters when we're *done* with Struts 2.0, not now. Based on our past history, I'd bet we're talking 12-18 months before a production quality release of 2.0 would be designed, developed, tested, and evolved to the point where we were happy enough to call it (and the APIs inside it) "stable." Because of how long it took for the J2EE 1.4 standards to go final (we were done with servlet and JSP last summer, but had to wait for the web services standards to go final), the various app server vendors are already well on the way towards 1.4 compliance. (Sun's certified server is already available, and is free for development AND production). In the open source world, Tomcat 5 already has production quality support, of course, and Jetty at least is not far behind (Greg is using Jasper2 for the JSP 2.0 stuff, so all he's got to do is catch up on the servlet 2.4 changes, which are pretty modest). > If it ends up being interface, so it could be even used from Soap or > applications (the discussed interface execute(Context ctx) ; ) it won't > matter much. > I agree that execute(Context ctx) is the right sort of method signature for the low level elements. Come to think of it, that's already the signature used in commons-chain :-). > .V > > ps: I would like light IoC to be considered just a bit more as platform, > Pico, Oscar. Not Spring or Avalon. > All of these are interesting, but I think there's two levels of IoC that need to be thought about: * How the various pieces of Struts itself glue themselves together. * How application level services are composed and made available. It seems to me that different choices are possible at these two levels, and that (if different) the former should be lighter weight than the latter. But we can't really pick particular technologies without having identified the needs and use cases first. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
