JSR88 does not validate deployment descriptors
I wonder whether it is the correct approach to validate the DDs
in the JSR88 layer. It seems more natural/correct to validate the
DDs in the subsystem that consumes the deployment. The behaviour I
would expect is that the (invalid) deployment reaches the server,
fails during deploy and that the deployment failure is
communicated back to the jsr88 layer.
JBoss OSGi Lead
JBoss, a division of Red Hat
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.
On Nov 30, 2011, at 16:59, Thomas Diesler wrote:
> this is related to
> [AS7-2854] JSR88 does not validate deployment descriptors
> I wonder whether it is the correct approach to validate the DDs in the JSR88 layer. It seems more natural/correct to validate the DDs in the subsystem that consumes the deployment. The behaviour I would expect is that the (invalid) deployment reaches the server, fails during deploy and that the deployment failure is communicated back to the jsr88 layer.
> Thomas Diesler
> JBoss OSGi Lead
> JBoss, a division of Red Hat
> jboss-as7-dev mailing list
> [hidden email] > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> I can just put in my 5 cents:
> Yep the only one to be happy is Max…
eh - I don't think I was talking about me - just talking about users in general.
> The problem is quite hard, external validation takes ages and adding the logic in the parser = metadata parser is a lot of work :-(
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.