I like the one api bean approach because then you don't have to remember the names of the objects to lookup in the context. You just remember one name and get the rest from that bean.
We don't need a migration path if we do this for 2.0, only for the 1.x series. I'm not sure which series you were planning on doing this in though?
I think it should definitely be a clear design constraint on anything 2.0, but I'd like to try to do it on 1.x too. I don't think that's *too* hard, since in most cases, Struts is doing the writing, especially to the Servlet context. I'm going to keep thinking about it and talking about it on the dev list, though. To be honest, my cycles aren't going to be going into a 2.0 revolution too soon; I'm expecting to stay focused on pushing Struts 1.x forward for a while.
My personal top priority is the chain request processor.
Other near term things I'm thinking about are:
* small changes to take advantage of our agreement on the move to Servlet 2.3 -- especially nesting exceptions anywhere they are caught and a JSP or ServletException are thrown. That should make debugging a bit easier.
* adding the properties to ActionConfig (hopefully this weekend. I'll do this on 1.3 and not worry about fitting it into the 1.2 branch. I realized the digester rules to achieve the config syntax Martin proposed will be a bit wonky, but not a stopper)
* providing an ActionForm method which returns ActionMessages from a validation method so we can push ahead on fully deprecating ActionErrors. (Also 1.3. I'll mention the strategy in another thread to help it be seen...)
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
