I can just put in my 5 cents: we don't prevent deployment in tools if there are validation errors since the server or frameworks are normally more lenient. We warn/error where we can, but does not prevent deployment. If there are errors that prevents deployment we expect the server to report them. i.e. example where too strict validation before deployment is if your war is saying it is 3.0 in the web.xml - if we had validated that against JBoss 5 which is reported to only support 2.5 it would not have been possible to deploy them even though it supported most web.xml v 3.0. Its always a balance. I would thus say the validation should be possible on both sides but the JSR88 shouldn't force validation errors to prevent deployment. /max On Nov 30, 2011, at 16:59, Thomas Diesler wrote: /max http://about.me/maxandersen

eh - I don't think I was talking about me - just talking about users in general. Did you read what I wrote ? :) I wrote the client/tools should provide ways to validate but not prevent deployment because the server side is normally more lenient (for one reason is that they tend to not validate well because thats not what they normally are concerned about) Of course I would appreciate if the frameworks actually kept more context so once they actually do get fed garbage they can point out or at least hint about what part of the garbage they don't like. But that was not what the question was about. It was wether client or servers should validate - and I just wanted to point out that if client tools validates before deployment they should have an option to ignore/skip the validation because the server might actually be handling it even though the client side validation says there is an error. /max http://about.me/maxandersen