>> I very much dislike changing the default behavior within a minor release or >> a milestone. But, if we can restrain the changes to the configuration, I suppose we could live with it.
Ted, perhaps you need to think about this more :) Unless there are plans to come up with a different solution for 1.3/1.4, I don't want to put into Struts a solution that you're going to immediately rip out for a better approach. And I don't say that because I put time into the patch... ;-) but because it will create anguish for developers, and who wants to buy into a solution you're virtually about to toss away? If the set-property is the way to go, let's do it. And if you want it into the DTD instead, we can do that too. It's just modifying the DTD. +1/-1 for the DTD? >> In any case, we should not just ignore the cancel token. If the token is >> present, and Cancellable is not set, then we should log the error and throw an exception so that the developer knows the contract is not being observed (or that the website is being spoofed). IMO, bad idea. What if you don't want to handle the cancel at all? That's how this whole thread started. The notion of canceling is semantically nonsensical for most actions that back a GET request (view airline ticket, view any item, etc.) The problem is not that the token is an intrinsic evil, but that the token is not always necessary. So you pass in a token of the CANCEL button and you're not handling it -- big deal. Whose to say that's incorrect behavior? It's only incorrect if the action is supposed to handle it but is not, and you need a requirements document for that ;-) It is my understanding that Exceptions are heavy-lifting, relatively speaking, compared to a normal non-exception execution path. Don't you think, devilishly speaking, it would be a great idea to write a loop that passes in the CANCEL token knowing the server will generate an exception every time? Unless I am overly scrupulous, I'd say that lays the foundation of a DoS attack, eating up alot of CPU to churn exceptions. Paul __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
