On Sun, 14 Mar 2004 11:34:10 -0600, Joe Germuska wrote: > At 11:59 AM -0500 3/14/04, Ted Husted wrote: >> On Fri, 12 Mar 2004 15:07:18 -0600, Joe Germuska wrote: > No one is more gung-ho about Struts Chain than I am, but people > should be aware that we're still just into beta with functionality. > Using it on my latest project, I've definitely found a few pieces > that hadn't yet been implemented. I've put in what I found missing > -- tiles and file upload -- but there are probably some other less > mainstream pieces that will turn out to be buggy or not even > implemented. We would probably want to make a branching CVS tag > for this if we do it. I don't have a lot of experience working on > branched codebases with a distributed team, so it should be an > interesting ride, but I think Struts Chain is far enough from ready > that we don't have a choice.
I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). > Plus, we need to push commons-chain to a full release. And what > about commons-resources? That sounded like it was pretty close. > Looking at http://jakarta.apache.org/struts/status.html , I think > that roadmap may be still be a good strategy -- get the resources > transition done for 1.3, then the new request processor for 1.4. > Can anyone summarize what's standing between here and moving to > commons-resources? I think Commons Chain can move up any time we wanted. It's just a matter of floating a vote. The Resources thing has been a longtime coming and should be stable. I wouldn't hesitate to do both Resources and Struts Chain in the HEAD now. > In general, I'm satisfied with targeting the "page prep" as a chain- > dependent feature. If we introduce a StrutsContext as the chain > implementation of o.a.c.chain.Context then we'll have to come up > with a Context factory process so that the > ComposableRequestProcessor can be given a Context instead of > instantiating one itself. My first hunch is that it should be an > early chain command which creates a sub-context of a specific type > and uses it to do most of the chain processing. > > Joe --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
