Use the Helidon MP Maven archetype to create a simple project that can be used for the examples in this guide.

mvn -U archetype:generate -DinteractiveMode=false \
    -DarchetypeGroupId=io.helidon.archetypes \
    -DarchetypeArtifactId=helidon-quickstart-mp \
    -DarchetypeVersion=2.6.14 \
    -DgroupId=io.helidon.examples \
    -DartifactId=helidon-quickstart-mp \
    -Dpackage=io.helidon.examples.quickstart.mp

cd helidon-quickstart-mp

Helidon has an internal configuration, so you are not required to provide any configuration data for your application, though in practice you most likely would. By default, that configuration can be overridden from three sources: system properties, environment variables, and the contents of META-INF/microprofile-config.properties. For example, if you specify a custom server port in META-INF/microprofile-config.properties then your server will listen on that port.

A main class is also required to start up the server and run the application. By default the Quickstart sample project uses the built-in Helidon main class. In this guide you want to use your own main class so you have more control over the server initialization. First define your own Main:

package io.helidon.examples.quickstart.mp;

import io.helidon.microprofile.server.Server;
import java.io.IOException;

public final class Main {

    private Main() { } 

    public static void main(final String[] args) throws IOException {
        Server server = startServer();
        System.out.println("http://localhost:" + server.port() + "/greet");
    }

    static Server startServer() {
        return Server.create().start(); 
    }

}

In this class, a main method is defined which starts the Helidon MP server and prints out a message with the listen address.

• Notice that this class has an empty no-args constructor to make sure this class cannot be instantiated.
• The MicroProfile server is started with the default configuration.

Next change the project’s pom.xml to use your main class:

    <properties>
        <mainClass>io.helidon.examples.quickstart.mp.Main</mainClass>
    </properties>

This property will be used to set the Main-Class attribute in the application jar’s MANIFEST.

In your application code, Helidon uses the default configuration when you create a Server object without a custom Config object. See the following code from the project you created.

    static Server startServer() {
        return Server.create().start(); 
    }

• There is no Config object being used during server creation, so the default configuration is used.

In order to properly configure your application using configuration sources, you need to understand the precedence rules that Helidon uses to merge your configuration data. By default, Helidon will use the following sources in precedence order:

1. Java system properties
2. Environment variables
3. Properties specified in META-INF/microprofile-config.properties

Each of these sources specify configuration properties in Java Property format (key/value), like color=red. If any of the Helidon required properties are not specified in one of these source, like server.port, then Helidon will use a default value.

The following examples will demonstrate the default precedence order.

Default Configuration Resource

app.greeting=HelloFromMPConfig

mvn package -DskipTests=true
java -jar target/helidon-quickstart-mp.jar

curl http://localhost:8080/greet
...
{
  "message": "HelloFromMPConfig World!" 
}

export APP_GREETING=HelloFromEnvironment
java -jar target/helidon-quickstart-mp.jar

curl http://localhost:8080/greet
...
{
  "message": "HelloFromEnvironment World!" 
}

java -Dapp.greeting="HelloFromSystemProperty"  -jar target/helidon-quickstart-mp.jar

curl http://localhost:8080/greet
...
{
  "message": "HelloFromSystemProperty World!" 
}

You can inject configuration at the field level as shown below. Use the volatile keyword since you cannot use AtomicReference with field level injection.

sources:
  - type: "classpath"
    properties:
      resource: "META-INF/microprofile-config.properties"  

• This example only uses the default classpath source.

@ApplicationScoped
public class GreetingProvider {

    @Inject
    @ConfigProperty(name = "app.greeting") 
    private volatile String message; 

    String getMessage() {
        return message;
    }

    void setMessage(String message) {
        this.message = message;
    }
}

• Inject the value of app.greeting into the GreetingProvider object.
• Define a class member variable to hold the greeting.

curl http://localhost:8080/greet
...
{
  "message": "HelloFromMPConfig World!"
}

You can inject the Config object into the class and access it directly as shown below.

import io.helidon.config.Config;
import javax.enterprise.context.Initialized;
import javax.enterprise.event.Observes;
...

@ApplicationScoped
public class GreetingProvider {
    private final AtomicReference<String> message = new AtomicReference<>();

    @Inject 
    public GreetingProvider(Config config) {
        String message = config.get("app.greeting").asString().get(); 
        this.message.set(message);
    }

    String getMessage() {
        return message.get();
    }

    void setMessage(String message) {
        this.message.set(message);
    }
}

• Add three new imports.
• Inject the Config object into the GreetingProvider object.
• Get the app.greeting value from the Config object and set the member variable.

curl http://localhost:8080/greet
...
{
  "message": "HelloFromMPConfig World!"
}

Helidon offers a variety of methods to access in-memory configuration. These can be categorized as key access or tree navigation. You have been using key access for all of the examples to this point. For example app.greeting is accessing the greeting child node of the app parent node. There are many options for access this data using navigation methods as described in Hierarchical Configuration and Advanced Configuration. This simple example below demonstrates how to access a child node as a detached configuration sub-tree.

app:
  greeting:
    sender: Joe
    message: Hello-from-config-file.yaml

sources:
  - type: "classpath"
    properties:
      resource: "META-INF/microprofile-config.properties"
  - type: "file"
    properties:
      path: "./config-file.yaml"

@ApplicationScoped
public class GreetingProvider {
    private final AtomicReference<String> message = new AtomicReference<>();
    private final AtomicReference<String> sender = new AtomicReference<>();

    @Inject
    Config config;

    public void onStartUp(@Observes @Initialized(ApplicationScoped.class) Object init) {
        Config appNode = config.get("app.greeting"); 
        message.set(appNode.get("message").asString().get());  
        sender.set(appNode.get("sender").asString().get());   
    }

    String getMessage() {
        return sender.get() + " says " + message.get();
    }

    void setMessage(String message) {
        this.message.set(message);
    }
}

• Get the configuration subtree where the app.greeting node is the root.
• Get the value from the message Config node.
• Get the value from the sender Config node.

curl http://localhost:8080/greet
...
{
  "message": "Joe says Hello-from-config-file.yaml World!"
}