WARNING: This server provides a static reference view of the NetKernel documentation. Links to dynamic content do not work. For the best experience we recommend you install NetKernel and view the documentation in the live system .


IntrayTransport is a transport that must be instantiated from a prototype.


The IntrayTransport prototype has the following initialisation parameters:

configOptionalIdentifier or XMLres:/etc/IntrayConfig.xml
Configuration for the Intray transport
An identifier for created logical endpoint, if omitted a unique auto-generated value it will be used.
If included this parameter will mark the endpoint as private and it will not be exposed outside module.

Here is an auto-generated example of how to instantiate an instance of IntrayTransport:

Import Requirements

To use IntrayTransport transport you must import the module urn:org:netkernel:tpt:intray:


The IntrayTransport is used to poll a filesystem directory for added files. When new files are detected they are removed from the directory and sent to the transport for processing. After processing they are then saved back into a different directory.


The config parameter must specify the configuration for the Intray transport. It should be a resource of the form...

  <in ext="xml">file:/home/pjr/temp/in/</in>
  <out ext="html">file:/home/pjr/temp/out/</out>
    <argument name="operator">res:/test/intray/processor.gy</argument>
    <argument name="file">arg:file</argument>

Where the elements are as follows:

  • in - the file: URI of a directory to monitor for files. This directory must exist and be readable by the current JVM process user.
  • out - the file: URI of a directory to write processed files. This directory must exist and be writable by the current JVM process user.
  • poll - the poll interval (in seconds) at which to look for new intray files.
  • request - a declarative request to issue for each file that is discovered (see request section below).
  • @ext - both the and tags take an optional ext attribute which indicates respectively that the input file must have that extension and when processed the output file will be written with that file extension. Hence if we have ... and ... then myfile.xml would be processed and written to the outtray as myfile.html

Regex Rewrite Mode

An advanced mode allowing regex matches on the filename with rewrites of the out box filename may be used as an alternative to the file extension filtering.

The following config would match all .txt files beginning foo and write the out box file with filename ending in baa and a new extension .xml

  <in regex="foo(.*)\.txt">file:/home/pjr/temp/in/</in>
  <out rewrite="$1baa.xml">file:/home/pjr/temp/out/</out>
    <argument name="operator">res:/test/intray/processor.gy</argument>
    <argument name="file">arg:file</argument>

Capturing groups in the regex match may be substituted into the rewrite filename using the conventional $x substitution marker.

Default config location

If the config parameter is not specified then the Intray Transport will attempt to find a configuration resource (of the same form) from res:/etc/IntrayConfig.xml


The request specified in the configuration must be a declarative request. For each file that is found in the intray an instance of this request will be constructed and issued into the space hosting the Intray endpoint.

To be useful the request needs to relay on the identity of the file resource. It should do this by referencing arg:file - whose reference in the declarative request will be replaced with the file: URI of the intray file.


For example suppose we have a configuration such as...

    <argument name="file">arg:file</argument>

Here the directory file:/home/pjr/temp/in/ will be monitored for new files. Lets suppose that a file named "hello.txt" is copied to this directory.

Upon discovering the file the Intray transport constructs a new request based on the declarative request template. The reference arg:file is replaced by the full URI of the intray file. So, in this case, the request that is constructed and issued by the Intray would be...


The requested service is responsible for dealing with the file as appropriate. Ultimately it returns a response to the Intray transport. The intray transport SINKs the response as a binary stream to the out tray directory specified. Here a file will be written to:


Finally upon successfully completing the processing, the original intray file is deleted.

Request Representation

The intray transport must always write a response to the out tray and so will always request an IBinaryStreamRepresentation, and will override any user specified representation type in the declarative request.