tjquinno

package com.mycorp.myapp;
public class MyEndpoints {

    @Inject
    Meter greetings;
    
    @Inject
    @Metric(name = "greetings")
    Meter myGreetings;
}

tjquinno

package com.mycorp.myapp;

public class MyEndpoints {
  
    @GET
    @Metered(name = "greetings")
    @Produces(MediaType.TEXT_PLAIN)
    public String greet() {...}
}

tjquinno

package com.mycorp.myapp;

public class MyEndpoints {

    @Inject
    MetricRegistry appRegistry;
    
    private Meter myMeter;
    
    public MyEndpoints() {

tjquinno

@Inject
MetricRegistry appRegistry;

Meter myMeter =
    appRegistery.meter("com.mycorp.myapp.MyEndpoints.greetings");

tjquinno

@Inject
MetricRegistry appRegistry;

Metadata metadata = Metadata.builder()
    .withName("com.mycorp.myapp.MyEndpoints.greetings")
    .withType(MetricType.METERED)
    .withDisplayName("Endpoint greeting requests")
    .build();

Meter myMeter = appRegistry.meter(metadata);

tjquinno

package com.mycorp.myapp;

public class MyEndpoints {

    @GET
    @Metered(name = "greetings", reusable = true)
    @Produces(MediaType.TEXT_PLAIN)
    public String greet() {...}
    
    @GET

tjquinno

Adding CORS to built-in Helidon services

We are adding CORS support to the existing built-in services for metrics, health, and OpenAPI. Users have asked specifically for Helidon OpenAPI to spuport CORS because of applications or sites like Swagger U/I. It seems reasonable that there might be sites or apps that act as front ends for the metrics or health information for one or more apps.

By default metrics, health, and OpenAPI will support CORS with these settings:

   allow-methods: ["GET", "HEAD", "OPTIONS"]

with the other settings defaulted. This is equivalent to:

 enabled: true

tjquinno

MP Metrics 2.3 Support

There are three key additions for us:

1. New SimpleTimer metric (combines a count and an elapsed time accumulator)
2. @SimplyTimed annotation
3. REST.request optional automatic metric in base registry for all REST endpoints. In MP, Helidon creates a SimpleTimer for each endpoint annotated with a JAX-RS annotation (@GET, @PUT, etc.), with name REST.request and tags class and method identifying the endpoint.

The spec leaves open how an MP implementation enables and disables the REST.request behavior. See below for our proposal.

Helidon MP

Recommendation:

tjquinno

Overview

There will be two projects. One is built and started ahead of time and has a very simple API:

• a GET that accepts a String and returns it upper-cased after waiting an amount of time (initialed to a delay of 0),
• a PUT that accepts a new delay time in ms.

Note that this app is unrealistically simple but illustrates service-calling-service and health in the main app.

The other project is the normal greeting one from helidon init with:

• an added liveness check that pings the other project’s up-case endpoint and reports “not ready” if it takes more than 200 ms to respond, and
• the two greet methods updated to invoke the up-case endpoint in the other app.

tjquinno

I did not want to continue the (bad) practice of copying code from existing `xxxSupport` and 
`xxxCdiExtension` classes into the new Micrometer classes. The Micrometer classes share 
considerable behavior with the Helidon metrics ones. You might remember that my first PR 
added the Micrometer classes to the existing metrics modules, and you (correctly) pointed 
out that would drag along unneeded dependencies.

When I then created the separate `integrations/micrometer` module, I rejected putting the common 
classes into either it or `microprofile/metrics` and have one depend on the other; that, too, 
would drag along unused dependencies.