On Thu, 18 Dec 2003, Craig R. McClanahan wrote: > 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.
It would certainly be technically feasible to do that, but are there practical advantages to doing so? The only thing I can think of is that it's easy to punt on a request and let something else (i.e. another filter or a servlet) handle it, but I'm not sure why I would want to do that. Any good examples? -- Martin Cooper > > * 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
