I have a problem with string-type parameter of a custom service when exporting artifacts from domain.
The parameter type is string and is used to specify paths (in url format, like 'sonicfs://somepath'), multiple entries separated with commas. Everything is fine and working in Workbench domain.
However, when trying to export artifacts with ESB Deployment Export Tool, the tool treats the string parameter as a file resource and tries to traverse and resolve the assumed file behind the parameter. That doesn't work when the parameter content is not a real file but a string with multiple sonicfs://... entries separated with commas. That also doesn't work when the parameter content is a folder, e.g. 'sonicfs:///workspace/sampleproject/somefolder', the tool gives the error that I attached.
If I remove the 'sonicfs://'-prefix from the parameter, the tool no longer assumes the paramer is a file and does not try to resolve any file from it. This however is a bad workaround from my point of view, because I really would like to have the parameter in url format (with 'sonicfs://' prefix) and handle it myself in the custom service.
Does anyone know why Deployment Export Tool tries to handle a string parameter of a process step as a file resource, even if the parameter type is just plain string?
Is this a bug or just normal behaviour?
I'm using 7.6 version.
This is actually a feature --- The idea is (for the purposes of 'reference traversal') to have all the artifacts referenced by one 'root' added to the exported .xar file.
...remove sonicfs...this is a bad workaround...
Thanks for the response.
I can see the reasongin behind the way Export Tool works in this case. The idea was that for a custom service, we could allow the process designer to specify a custom, additional, classpath for the service invocation. The classpath could contain multiple entries, separated with commas, and also directory entries. This of course means the designer would have to include those entries to the deployment package explicitly.
So far our workaround has been to put the needed stuff to one jar file; that works because it is a valid sonicfs entry.
I quess there is some rethinking for me to do.
- Tatu V.