Configuring the Server

By default, the server uses the MicroProfile Config, but you may also want to use Helidon configuration.

Configuring the Server

There are 3 default MicroProfile Config sources:

  • System.getProperties()

  • System.getenv()

  • all META-INF/microprofile-config.properties files on the class path

  • application.yaml on the classpath (read by default by Helidon Config)

In this example, the configuration is in a file, and it includes Helidon configuration options.

META-INF/microprofile-config.properties - Server configuration
# default is localhost
server.host=some.host
# default is 7001
server.port=7011

# Helidon configuration (optional)

# Length of queue for incoming connections. Default is 1024
server.backlog=512
# TCP receive window. Default is 0 to use implementation default
server.receive-buffer=256
# Socket timeout milliseconds - defaults to 0 (infinite)
server.timeout=30000
# Defaults to Runtime.availableProcessors()
server.workers=4
Copied

Configuring TLS

Helidon MP also supports custom TLS configuration.

User is able to set following properties:

  • Server truststore

    • Keystore with trusted certificates

  • Private key and certificate

    • Server certificate which will be used in TLS handshake

META-INF/microprofile-config.properties - Server configuration
#Truststore setup
server.tls.trust.keystore.resource.resource-path=server.p12
server.tls.trust.keystore.passphrase=password
server.tls.trust.keystore.trust-store=true

#Keystore with private key and server certificate
server.tls.private-key.keystore.resource.resource-path=server.p12
server.tls.private-key.keystore.passphrase=password
Copied

Or the same configuration done in application.yaml file.

application.yaml - Server configuration
server:
  tls:
    #Truststore setup
    trust:
      keystore:
        passphrase: "password"
        trust-store: true
        resource:
          resource-path: "keystore.p12"
    #Keystore with private key and server certificate
    private-key:
      keystore:
        passphrase: "password"
        resource:
          resource-path: "keystore.p12"
Copied

Configuring additional ports

Helidon MP can expose multiple ports, with the following limitations:

  • The default port is the port that serves your application (JAX-RS applications and resources)

  • Other ports (in this example we configure one "admin" port) can be assigned endpoints that are exposed by Helidon components, currently supported by MP Health and MP Metrics

For this example, we will use a yaml file:

  • The port 7011 is the default port and will serve your application

  • The port 8011 is named "admin" (this is an arbitrary name)

  • MP Metrics are configured to use the "admin" port through the routing configuration (reference is by name)

  • MP Health is configured the same way to reference the "admin" port

application.yaml - Server configuration
server:
  port: 7011
  host: "some.host"
  sockets:
    admin:
      port: 8011
      bind-address: "some.host"

metrics:
  routing: "admin"

health:
  routing: "admin"
Copied

Assigning JAX-RS applications to ports

Since 1.4

Helidon has the concept of named routings. These correspond to the named ports we have described in the previous section.

You can assign a JAX-RS application to a named routing (and as a result to a named port) using either an annotation or configuration (or both to override the value from annotation).

Annotation @RoutingName

You can annotate an application with this annotation to assign it to a specific named routing, that is (most likely) going to be bound to a specific port.

The annotation has two attributes: - value that defines the routing name - required to mark that the routing name MUST be configured in Helidon server

@RoutingName example
@ApplicationScoped
@ApplicationPath("/admin")
@RoutingName(value="admin", required="true")
public class AdminApplication extends Application {
//....
}
Copied

The example above will be bound to admin routing (and port) and will fail if such a port is not configured.

Configuration override of routing name

For each application class you can define the routing name and its required flag by specifying a configuration option class-name.routing-name.name and class-name.routing-name.required.

Example (YAML) configuration for a class io.helidon.examples.AdminApplication that changes the routing name to management and its required flag to false:

io.helidon.examples.AdminApplication:
  routing-name:
    name: "management"
    required: false
Copied

Overriding JAX-RS application path

Since Helidon 1.4 In JAX-RS we can use @ApplicationPath to configure a path the JAX-RS application is available on. As this is compiled into the source code, Helidon provides a way to override this using configuration.

For each application class you can define the routing path by specifying a configuration option class-name.routing-path.path.

Example (YAML) configuration for a class io.helidon.example.AdminApplication that changes the routing path to /management:

io.helidon.examples.AdminApplication:
  routing-path:
    path: "/management"
Copied

Configuring requested URI discovery

To set up requested URI discovery for your server, add a requested-uri-discovery section to your configuration. You can define different behavior for each socket in your server, including the default socket.

Configuring Request URI Discovery (properties format)
server.port=8080
server.requested-uri-discovery.types=FORWARDED,X_FORWARDED
server.requested-uri-discovery.trusted-proxies.allow.pattern=lb.*\\.mycorp\\.com
server.requested-uri-discovery.trusted-proxies.deny.exact=lbtest.mycorp.com
Copied

This example might apply if mycorp.com had trusted load balancers named lbxxx.mycorp.com except for an untrusted test load balancer lbtest.mycorp.com.

Example configuration of JAX-RS application

A full configuration example (YAML):

server:
  port: 8080
  sockets:
    management:
      port: 8090

io.helidon.examples.AdminApplication:
  routing-name:
    name: "management"
    required: true
  routing-path:
    path: "/management"
Copied