ESB Deployment Export Tool treats string parameter as a file

Posted by tvanhane on 12-May-2009 14:29

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.

Thanks,

-TV

export-tool-error.jpg

Technology Partner - Forum

All Replies

Posted by Bill Wood on 11-Oct-2009 08:44

Is this a bug or just normal behaviour?

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.

All strings and text files are introspected for 'sonicfs' urls in order to catch these.  (The reason string are done is that sometimes one file/string can contain references to others -- e.g. a XSLT, or JavaScript file might refer to a sonicfs:/// import or properties file.

...remove sonicfs...this is a bad workaround...

A suggestion:

  • There is a list of excluded resources (in the ExportProperties.xml) file.   This list is a set of items that are not to be traversed.  If you add your sonicfs file reference to this, then the Export tool will still find the sonicfs reference, but it will ignore it and not do any reference traversal.

Posted by tvanhane on 21-Apr-2010 02:40

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.

This thread is closed