[
https://jira.jboss.org/jira/browse/JBPM-2762?page=com.atlassian.jira.plug...
]
Ronald van Kuijk commented on JBPM-2762:
----------------------------------------
The reason for this behaviour is related to JBPM-2166. Tom Baeyens wants extensibility in
the same namespace (where I prefer using different namespaces) So until JBPM-2166 is
solved, the choice was made (I assume, but have strong suspicions in this direction) to
'ignore' these errors and just ignore them. And until JBPM-2166 is solved, I would
not try to change the api since there could be changes later in what happens behind the
api, in the implementation.
Since you can retrieve the definition (in xml format) from a deployment after it has been
deployed and act upon it (what is actually the reason to have the extensibility) and there
is no real way to decide what is correct and wrong by the jPDL parser (other then the jPDL
tags it knows), this behaviour is the 'best' that can be achieved.
So if Toms preference is implemented, this issue is 'invalid' if my preference is
implemented (please add comment to JBPM-2166) it is indeed something that should be
changed.
XML Schema Validation errors in jpdl files don't get reported
when deploying them
---------------------------------------------------------------------------------
Key: JBPM-2762
URL:
https://jira.jboss.org/jira/browse/JBPM-2762
Project: jBPM
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: jBPM 4.3, jBPM 4.2
Reporter: Erwin Bolwidt
When I deploy an invalid JPDL file (take a valid file, add <abc/> at some random
location, voila) through the RepositoryService, the deployment succeeds. I can see that
the validation error is reported internally, but an exception is not thrown.
It is also not possible for the caller to determine that there was a validation error,
unless the caller is willing to cast NewDeployment to DeploymentImpl and invoke the
methods from the ProblemList superclass.
The thing is, DeployerManager (line 49, jbpm 4.3) checks that there haven't been any
errors using ProblemList#hasErrors(). And ProblemList#hasErrors() returns true if there is
at least one problem with severity ProblemImpl.TYPE_ERROR. However, validation errors are
reported with severity ProblemImpl.TYPE_XML_VALIDATION_ERROR.
Of course I don't know the reasons why the developer of this code choose this
implementation, but to me it seems that this was an oversight and the hasErrors() should
have checked for TYPE_XML_VALIDATION_ERROR as well.
I haven't had a chance yet to see how a process definition with an invalid jpdl file
functions in practice, but it doesn't seem right that you can deploy an incorrect
process definition.
And if it was right, for some reason, then I think the caller should have a chance to
find out, so in that case the interface NewDeployment could be extended with methods to
retrieve any problems during deployment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira