Validation succeeds despite throwing exception #33
Comments
|
@jbrumf can you please attach the schema/schematron you are using, the product that is failing validation, and any other additional information that may help us debug? also, have you tried this again with v1.15.0 of validate? we have several bug fixes in that version that may be able to help you. https://pds-engineering.jpl.nasa.gov/development/pds4/current/preparation/validate/index.html |
|
Many thanks. I will try v1.15.0 first. If that doesn't fix it, I will post the schema and product XML files. |
|
We upgraded to validator 1.15.0 and pds4-tools 0.12.0 and now get a slightly different exception. We think the problem is that the method setRegisteredProducts() is only called when the validator is called by command line (using the main[] method). We are creating an instance of ValidateLauncher in Java code but we can't call the setRegisteredProducts method because it is private. We need to configure the JSON file with the registered products. How should we do this? |
|
I have attached a ZIP containing the files which you requested: |
|
In case it helps this is the stack trace of the exception raised during the validation (using 1.15.0 version): 2019-07-05 15:28:51 ERROR Unexpected exception executing validation rule |
|
More in detail, it seems a null 'sysid' variable in Utility.fixSlashes(): |
|
(updated) |
|
One more thing, sorry. We tested the validation tool from the command line, using the stand-alone application provided in the package and using two different setups:
In neither of the two cases the tool raises any exception but the first case reports three problems for our label file while the second execution only reports one problem. My conclusion is that the validation is correctly executed when the schemas and schematrons are provided explicitly (first case) and it gets interrupted in the second case when the same NullPointerException problem is found. Seems that the code handles this exception internally and stops the validation before it is finished without reporting any problem to the stdout, just the validation status up to that moment. |
|
@josinde I poked into this, and haven't quite been able to track down the solution, but I was able to easily replicate the problem. it looks like once the label invalidates, for some reason when a catalog file is involved, it just stops validating anything else after that. that being said, once I fixed the problem in the label, and re-ran validate, it completed all of the validation successfully. so in the meantime, I think the workaround would be to fix the validation errors you are getting in the labels, and then re-run validate to see if any additional errors exist (e.g. context products, context validation, etc.) |
|
@jordanpadams Thanks for look into this. Being able to reproduce the problem in your side are already a good news. We run the validator integrated in our own software and I need to check that the code reports a label problem even when this exception is raised. If this is the case your proposal could perfectly work for us. In case it helps to the solution, what I found is that checking the sysid value in the Utility.fixSlashes() method the code returns a full validation report without exceptions as if no catalog were configured. Seems that at one point in the label validation it needs to resolve the schema locations. When a catalog is used, this process triggers the following sequence of invocations: XMLCatalogResolver.resolveResource(..) -> Utility.makeAbsolute() -> Utility.fixSlashes() and this last method raises the NullPointerException when the input argument is null. I don't know why the code ends up resolving a location with null sysid and understand this should be great but at least this can work as a temporal workaround. |
…rce, if systemId is null, we should just return null before trying to resolve it. Resolves #33
Similar to the functionality in CachedLSResourceResolver.resolveResource, if systemId is null, we should just return null before trying to resolve it. Resolves #33
|
@jordanpadams You are right, #49 and this seems to be the same issue. Thanks for spotting this. Looking forward to have the patch finally integrated in the code. |
|
@jordanpadams Seems like this patch works. Although, I still can't seem to figure out why systemId is null in this case. SystemId should always be set to the schema or schematron URL and in this instance, it seems to be null because of the following error in the label: I'm tempted to recommend that instead of simply returning null, maybe it might be worthwhile to add reporting a warning message so as to not hide any issues that may come about in the future, something like: |
Issue #33: Ignore resources with null systemId
|
@jordanpadams New snapshot tested locally and working as expected, including a new warnign when a null sysId is detected. Many thanks! Output logs: |
|
Same test removing the 'resources' problem: |
The validator (1.14.0) sometimes reports no errors even though it has thrown a NullPointerException during the validation process. This leaves me wondering whether there is actually an error in the XML. The exception message doesn't give a line number, so I don't know where in the XML the problem occurs.
Please see the attached output.
ValidationLog.txt
The text was updated successfully, but these errors were encountered: