Forum Discussion
TNeuschwanger
13 years agoChampion Level 1
SOLVED:
Add a custom project property using the -P directive on the command line. Using the name and value from that directive, use property expansion in the "Project Properties" tab to change the "Hermes Config" value...
So, on the command line add a -P directive such as -P"HermesConfigPath=file:///C:/.hermes" as a Windows OS example.
Within the SoapUI "Project Properties" tab, find the "Hermes Config" Property and make it's value be ${#Project#HermesConfigPath}
Within the SoapUI "Custom Properties" tab, add a "Name" of HermesConfigPath and a "Value" of file:///C:/.hermes
That "Value" should be the path that you normally use and you won't have to adjust it on the command line unless you need to. When you run the project on a remote Linux computer however, you can then point it to the Linux file structure path when run from a command line without needing to adjust the SoapUI project.
Note the use of the "file:///..." syntax. The loading of the hermes-config.xml file location expects a URL, so if you provide this syntax to the file path, you will eliminate a warning in the soapui-log file that is generated when it cannot load from a URL. The warning information is a little alarming as it attempts file mode operation if it does not find URL mode to its satisfaction to the valid hermes-config.xml file.
Warning generated when value is: c:/.hermes
No warning generated when value is: file:///c:/.hermes
This comes in handy when you are developing your SoapUI projects on a local windows box and use a continuous integration scheduler such as Jenkins running on a Linux computer. You want to have the same SoapUI project be able to run from either OS without maintenance.
Add a custom project property using the -P directive on the command line. Using the name and value from that directive, use property expansion in the "Project Properties" tab to change the "Hermes Config" value...
So, on the command line add a -P directive such as -P"HermesConfigPath=file:///C:/.hermes" as a Windows OS example.
Within the SoapUI "Project Properties" tab, find the "Hermes Config" Property and make it's value be ${#Project#HermesConfigPath}
Within the SoapUI "Custom Properties" tab, add a "Name" of HermesConfigPath and a "Value" of file:///C:/.hermes
That "Value" should be the path that you normally use and you won't have to adjust it on the command line unless you need to. When you run the project on a remote Linux computer however, you can then point it to the Linux file structure path when run from a command line without needing to adjust the SoapUI project.
Note the use of the "file:///..." syntax. The loading of the hermes-config.xml file location expects a URL, so if you provide this syntax to the file path, you will eliminate a warning in the soapui-log file that is generated when it cannot load from a URL. The warning information is a little alarming as it attempts file mode operation if it does not find URL mode to its satisfaction to the valid hermes-config.xml file.
Warning generated when value is: c:/.hermes
No warning generated when value is: file:///c:/.hermes
This comes in handy when you are developing your SoapUI projects on a local windows box and use a continuous integration scheduler such as Jenkins running on a Linux computer. You want to have the same SoapUI project be able to run from either OS without maintenance.
- MatthiasBuck8 years agoOccasional Contributor
Hi Todd,
We tried to follow the same approach but when trying to reference the project custom property within the SoapUI "Project Properties" tab, we're getting following error:
javax.naming.NamingException: Session name 'QM_BUILD_DEV' does not exist in Hermes configuration or path to Hermes config ( ${#Project#HermesConfigPath} )is not valid! error at line: 8 We are positive that the session name exists in the hermes config xml file.
To be clear, besides referencing the project custom property in the "Project Properties" tab, we're then also trying to overwrite the project custom property via -P option on the command line testrunner.sh call. This seems irrelevant to the issue because the reference to the path variable doesn't seem valid in the first place.
Any ideas? How did it work for you? Are you truly referencing it successfully?
Thanks in advance!
Related Content
- 10 years ago
- 4 years ago
Recent Discussions
- 15 years ago