On the surface it looks like you're combining two different things. There is a generic file with contents, and there are Configuration Files with grammar that know how to interpret the file, and parse it in a Name/Value format.
Can you attach the XML file you're working, what grammar file you might be associating this XML with, with and what you're trying to check for?
i am going to guess that the < > and other characters are messing up the 'contains' operator. perhaps the compliance bit isn't properly escaping those characters.
I think the issue here is that you are trying to look at the content of a file rather than using a proper grammar file to parse the XML and evaluate keys and values. Try creating a config file and use the xml grammar, then look for the key named init-param (to check if it exists), and then look for a key named param-name which contains value listOrders.
That would most likely work a lot better.
I made a test and it works very well. First create a local config object like this (adjust the path for your file):
Then create your rule like this:
I made a simple XML file to test it and it works. Here's what I tested against:
<init-param> <param-name>listings</param-name> <param-value>false</param-value> </init-param>
By the way, your example compliance rule is not using the config file you created, it's pointing to the File type object instead and comparing the Contents of the file. You are not using the configuration file itself.
Attached is the xml file.
Below is the scenario -
We have written a NSH script to find the location of xml file(web.xml and server.xml) of particular location. Once location of a files is identified by the script then we have created compliance rule for web.xml to validate the contents of the web.xml file but we are getting error while validating as mentioned in the previous conversion but same rule is successfully validated for server.xml file so I don't think so rule is invalid.
web.xml 159.2 K
If you have a script to find the file, why don’t you do the pattern search in the script and spit out ‘pass’ or ‘fail’ or something ?
Ahh I see the issue then, but there's no solution for this in the current release. When using the XML grammar you can can evaluate a specific path (path to the XML tag and it's value), but when you can have multiple tags of the same type at the same level it complicates things as they become indexed (i.e. web-app/servlet, web-app/servlet-1, etc...) so you could use wildcards to check if there is one servlet that contains a init-param with a param-name of listings, but you wouldn't be able to also check if there is another param-value with value false at the same level. You can only evaluate them separately.
So, the only option for you is to use your own custom script that would do the evaluation, and would then return a simple output that can be parsed by a grammar file, for example, in Windows INI format.
The output would have to be something like this:
Or whatever key/values you want to be able to evaluate with a compliance rule. Basically, the script does the compliance logic, and only returns the compliance result which is what you would evaluate in the compliance job. We've done this often in the past where the simple compliance rule language was not smart or advanced enough to satisfy the requirements. We have used Perl for example, to do this. The only issue with that is that if you need to see the raw values that were being evaluated, you'll need another version of the same script that outputs the values instead of the compliance result.
Great minds think alike