Kauri Documentation
13 RuntimeBook Index13.2 connectors.xml reference

13.1.2 Element description wiring

The root element. virtualHosts

This element is optional.

This element is used in case you want your application to handle requests for different virtual hosts.

Remember that one Kauri Runtime instance usually corresponds to one application. If you have multiple applications that you want to associate with different virtual hosts, you would rather launch these as separate Kauri instances, and use other techniques such as putting an Apache httpd instance in front to distribute the requests to the different Kauri instances.

Attributes: virtualHost


We demonstrate the use of virtual hosts and the purpose of the canonicalUri's using an example.

  <virtualHosts default="web">
    <virtualHost name="static" hostDomain="static.kauriproject.org" canonicalUri="http://static.kauriproject.org"/>
    <virtualHost name="web" hostDomain="www.kauriproject.org" canonicalUri="http://www.kauriproject.org"/>

    <artifact id="webmodule" ...>
      <inject-restservice name="static" ref="staticmodule:files"/>
      <mount name="myservice" path="/foo" virtualHost="web"/>

    <artifact id="staticmodule" ...>
      <mount name="files" path="" virtualHost="static"/>



Suppose the webmodule generates a page with a template that creates a link as follows:

<a href="${publicUri('service:/static/downloads/bar.zip')}">bar.zip</a>

The purpose of the publicUri() function is to translate the service-URI in the argument to a public URI. The "static" service of the webmodule is provided by the "files" service of the staticmodule, which is mounted on the path "" on the virtualHost static. Since the virtual host is different from the request to the webmodule, the publicUri() function will generate an absoute URI: http://static.kauriproject.org/downloads/bar.zip. modules

The modules element is the most important part of the runtime configuration: it specifies which modules to launch, and the wiring of the services between them.

Modules can be specified in three ways: using file references, using artifact references, or by specifying a directory containing module jars.

Each module is identified by a unique id. Within the wiring.xml, this is used for describing the wiring between the modules. At runtime, it may be used for informational or error messages.

The order in which the modules are defined is important. It is in this order that the modules will be started. The wiring between the modules needs to be such that there are no forward references to modules which are not yet launched. To put it in another way, the Kauri Runtime is currently not smart enough to figure out the startup order itself. file

Specifies a module using a file reference.

Might be useful sometimes, but in general we recommend to refer to modules as artifacts.

Attributes: artifact

Specifies a module using a Maven repository reference.

Attributes: directory

Using directory, you can tell the runtime to launch all the modules jars in the specified directory (non-jar files will be ignored).

The modules will be loaded in alphabetical order according to their file name.

When using directory, explicit wiring between modules and mounting of restservices is not possible.

Attributes: mount

Mounts a REST-service exported by a module on certain path of a certain virtual host, to make it available for access from outside the application.

Attributes: inject-restservice

This is used to wire a REST-service dependency of a module.

If a module's Spring config contains kauri:import-restservice elements, then you use inject-restservice to connect the restservice.

REST-service dependencies can be connected to REST-services that are exported by other modules, or to arbitrary URIs.



Suppose we have two modules called module A and module B.

Module A exports (= provides) a REST-service in its Spring config:

<kauri:export-restservice name="foo" ref="beanId1"/>

Module B imports (= depends on) two REST-services in its Spring config:

<kauri:import-restservice name="bar1" ref="beanId1"/>
<kauri:import-restservice name="bar2" ref="beanId2"/>

Now, let us connect the "bar1" dependency of module B to the "foo" service provided by module A. The "bar2" dependency will be connected to an arbitrary URL.

    <artifact id="moduleA" groupId="mygroup" artifactId="artifactA" version="1.0"/>

    <artifact id="moduleB" groupId="mygroup" artifactId="artifactB" version="1.0">
      <inject-restservice name="bar1" ref="moduleA:foo"/>
      <inject-restservice name="bar2" ref="url(http://myservice.org/something/)"/>

Note that the order of the modules is important: in the ref attribute you can only refer to modules that come before the current one. About REST-service types

It is possible to declare a type attribute on the kauri:import-restservice and kauri:export-restservice elements. This is optional, but if it is declared on both the import and export of two wired services, then these types need to be equal or an error will be given. The REST-service type is just a free-form string. inject-javaservice

This is used to wire a Java-service dependency of a module.

Note that wiring Java services is optional. Since Java services are typed, the Runtime can auto-wire dependencies on a certain type of Java service as long as there is only one provided service for that type.


When performing the wiring for a particular dependency, the Runtime will first see if there is an inject for this particular dependency, identified by name. If that is not the case, it will look if there is an inject for the type of service. If that is not the case, the Runtime will auto-wire the dependency by looking in the global Java service registry for a service of that type. If there would be more than one available, or none, an error will be thrown.

13 Runtime13.2 connectors.xml reference