Examples: multiple ports

[barchetta]

Fixes #2815

Also adds int port(String name) to ServerCdiExtension

[tjquinno]

I came at this by considering how a user might convert our classic MP greeting app to use multiple routing names.

First choice: add @RoutingName to the PUT method for changing the greeting

Ideally, there would be the obvious change to config and then one line of change in the code: add @RoutingName("private") to the PUT method on the existing resource. The public port would be available to outside requests but not the private one so only internal users could change the greeting.

This will not even compile because the @RoutingName annotation is defined to apply only to types. Ideally, it would work on methods as well.

Second choice: add @RoutingName to the resource classes

The next best would be to create two resources, one for the public endpoints with @Path("/greet") and the second annotated with @RoutingName("private") @Path("/greet/greeting") for the private ones. That builds but does not work as desired; the app endpoints (/greet and /greet/greeting) seem available on both the default routing and the private one so it looks as if the @RoutingName on resources is ignored.

Last choice: split the existing resource and create two Application classes (as you've had to do)

So, are we really telling developers that to use this feature they need take the quick-start example (or their own app), create two Application classes so they can specify the @RoutingName("private") on one and then write their respective getClasses methods, and also divide the resource class into two different resource classes so each application can report its own resource?

Ugh.

Even with the first and second choices not possible, it would be good in our example to at least preserve the external API of the greeting app. I tried binding the "public" resource to the path /greet and the "private" one to /greet/greeting and that seems to work. Trying to PUT to the public port returns a 405 Method Not Allowed which makes sense.

[barchetta]

@tjquinno I experimented with those first two options as well with the same results.

[tjquinno]

@barchetta It might be worth seeing if the @RoutingName processing could be changed so one of the first two approaches would work.

[tjquinno]

Maybe add some additional negative-expected probes? Otherwise LGTM.

[tomas-langer]

LGTM, please see the comment