Default properties/configuration discovery

[John D. Ament]

All,

Wanted to ask the question something I was playing with.  I wanted to see if I could do service registration in a generic fashion.  E.g. via a plain CDI extension, have something that registers a Microprofile service with a service locator.  One issue I see is the capture of listening port.  I was wondering, would it make sense to standardize certain configuration values, such as listening address and listening port within Microprofile? So that someone leveraging the Configuration API could query to get those values for whatever reason they may have?

John

[Emily Jiang]

Sorry, John! I don't quite understand your question. Do you mean to standardise the valid config value for a listening port etc? Can you demonstrate in code sample?

Emily

[Jérémie Lagarde]

Hi John,

For me, it's an excellent idea to standardize some container properties like the listening ports or JNDI entries. 

Some examples :

• container.name
  
• container.version
• container.ports.default.http
• container.ports.default.https
• container.ports.default.ejb
• container.managment.url
• microprofile.version

And why not a standard one to show all properties at startup (verbose mode for microprofile-config)

• microprofile.config.verbose

In my implementation, I a have an ApplicationServerPropertyProvider that retrieve some properties like ports from my Wildfly.  And a property like "service.configuration.verbose" to show all properties with the computed value and the provider name. If we can standardize this in MicroProfile that can be cool.

Regards,

Jérémie.

[Ondrej Mihályi]

Hi,

Standard config properties are a great idea, although it could be created as a separate proposal from the config specification, which really solves only the API to access the configuration values.

I understand that John A. proposes that the container exposes runtime information via standard properties. For example, if an application wants to find out on which HTTP port the server is listening, it would just request the configuration value under a standard key, e.g. container.port.http. In code, John's usecase could look like this:

@Inject

@ConfigProperty(name = "container.port.http")

int serverPort;

...

public void onStartup() {

    registerService(ipAddress, port);

}

For this usecase, we woud probably need more, e.g. context root, but that's a detail.

We could go even further and specify that these container properties are configurable in the configuration of a container, e.g. via system properties. Wildfly Swarm e.g. supports swarm.http.port system property, which specifies a port to listen to. Payara Micro supports payaramicro.port system property which does the same.

Then we could use the same standard property name to redefine the service port, e.g. java -jar microprofile-service.jar -Dcontainer.port.http=8080

I see a value in this, either as a part of the next version of config spec, or a separate (small) proposal to unify common properties.

--Ondrej

Dňa štvrtok, 6. apríla 2017 1:18:05 UTC+2 Jérémie Lagarde napísal(-a):

[John D. Ament]

Emily,

Basically what Ondrej has listed is what I'm thinking of, with Jeremie providing some great examples of properties we may want.

Basically, can we define some finite list of properties that are built in - simply because I'm on a Microprofile container.  

John

[Ondrej Mihályi]

Hi Alasdair,

You replied only to me, but I assume you wanted to reply to the mailing list - I hope this ends up in the correct thread.

Liberty supports listening on multiple http ports, so if there was a contianer.port.http property what should it look like?

This is exactly the point for some standardization, don't you think? Payara Micro also supports listening on multiple ports (although it's not straightforward to configure), but each container provides different means to configure the ports. Each container could provide it's own way to configure the ports and other common stuff, but I believe all could support a simple common denominator. However, I wouldn't like to discuss details, we could do that if we agree that there's a value in standardization. 

Also this information is available in the HttpServletRequest so if read only is required shouldn’t it already be available?

In MicroProfile, HttpServletRequest is not available, since only JAX-RS is included (no Servlet API is guaranteed). Moreover, in John's case, he would like to know the configuration at application startup, even before an application receives a request. 

I would like to know whether enough people see a value in the standardization of these common properties. If yes, then it's worth to create a proposal or add a PR to the config spec and then we can discuss the details. I believe that developers would welcome standardization in this area.

--Ondrej

2017-04-07 2:33 GMT+02:00 Alasdair Nottingham <alasdair....@gmail.com>:

I always get a little antsy when these things get discussed. I don’t know about other application servers, but Liberty supports listening on multiple http ports, so if there was a contianer.port.http property what should it look like? Also this information is available in the HttpServletRequest so if read only is required shouldn’t it already be available?

Alasdair

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c23e84ab-0e64-46cb-9366-57dbb2dc8f42%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[alasdair....@gmail.com]

I did mean to reply to all so it went to the list.

On Thursday, 6 April 2017 20:59:45 UTC-4, Ondrej Mihályi wrote:

Hi Alasdair,

You replied only to me, but I assume you wanted to reply to the mailing list - I hope this ends up in the correct thread.

Liberty supports listening on multiple http ports, so if there was a contianer.port.http property what should it look like?

This is exactly the point for some standardization, don't you think? Payara Micro also supports listening on multiple ports (although it's not straightforward to configure), but each container provides different means to configure the ports. Each container could provide it's own way to configure the ports and other common stuff, but I believe all could support a simple common denominator. However, I wouldn't like to discuss details, we could do that if we agree that there's a value in standardization. 

There are a few ways this makes me nervous and that is why I agree that we should discuss this separately from the current config proposal. 

Things that make me nervous about it:

*) the examples are always expressed in terms of an assumption of a single port, single host. This probably makes sense for a micro service, but I expect these API's to be used in non-micro service environment where multiple http endpoints could be configured.

*) If I ran two applications in a server then I would potentially expect different values for different applications, not sure how this works with the current proposal. 

*) I get concerned about how this interacts with existing behaviour. I wouldn't want to add this to my app server if it resulted in some kind of breaking change. This makes me nervous, but I doubt anyone else cares that much :).

I'm much more comfortable with read only than read write at this point. I'm not saying this in an attempt to block discussion, just to make it clear why I personally don't jump on doing this.

 

Also this information is available in the HttpServletRequest so if read only is required shouldn’t it already be available?

In MicroProfile, HttpServletRequest is not available, since only JAX-RS is included (no Servlet API is guaranteed). Moreover, in John's case, he would like to know the configuration at application startup, even before an application receives a request. 

I would like to know whether enough people see a value in the standardization of these common properties. If yes, then it's worth to create a proposal or add a PR to the config spec and then we can discuss the details. I believe that developers would welcome standardization in this area.

That is true, I guess I forgot because you can use @Context to inject it and I guess I assume it means the HttpServletRequest needs to be available in the JAX-RS spec, but maybe it is only if available. I haven't read the spec well enough.

[John D. Ament]

On Thursday, April 6, 2017 at 9:23:50 PM UTC-4, alasdair....@gmail.com wrote:

I did mean to reply to all so it went to the list.

On Thursday, 6 April 2017 20:59:45 UTC-4, Ondrej Mihályi wrote:

Hi Alasdair,

You replied only to me, but I assume you wanted to reply to the mailing list - I hope this ends up in the correct thread.

Liberty supports listening on multiple http ports, so if there was a contianer.port.http property what should it look like?

This is exactly the point for some standardization, don't you think? Payara Micro also supports listening on multiple ports (although it's not straightforward to configure), but each container provides different means to configure the ports. Each container could provide it's own way to configure the ports and other common stuff, but I believe all could support a simple common denominator. However, I wouldn't like to discuss details, we could do that if we agree that there's a value in standardization. 

There are a few ways this makes me nervous and that is why I agree that we should discuss this separately from the current config proposal. 

Things that make me nervous about it:

*) the examples are always expressed in terms of an assumption of a single port, single host. This probably makes sense for a micro service, but I expect these API's to be used in non-micro service environment where multiple http endpoints could be configured.

*) If I ran two applications in a server then I would potentially expect different values for different applications, not sure how this works with the current proposal. 

*) I get concerned about how this interacts with existing behaviour. I wouldn't want to add this to my app server if it resulted in some kind of breaking change. This makes me nervous, but I doubt anyone else cares that much :).

I'm much more comfortable with read only than read write at this point. I'm not saying this in an attempt to block discussion, just to make it clear why I personally don't jump on doing this.

Truth be told, even Hammock supports multiple port bindings.  However, only one port is considered the application port.  Other ports are more or less unmanaged, so for me those ports wouldn't be considered in this use case.  However, Microprofile still doesn't describe what deployment means.  Does Liberty maintain the notion of a primary port, or primary binding?  And would that be satisfactory for this use case?

 

 

Also this information is available in the HttpServletRequest so if read only is required shouldn’t it already be available?

In MicroProfile, HttpServletRequest is not available, since only JAX-RS is included (no Servlet API is guaranteed). Moreover, in John's case, he would like to know the configuration at application startup, even before an application receives a request. 

I would like to know whether enough people see a value in the standardization of these common properties. If yes, then it's worth to create a proposal or add a PR to the config spec and then we can discuss the details. I believe that developers would welcome standardization in this area.

That is true, I guess I forgot because you can use @Context to inject it and I guess I assume it means the HttpServletRequest needs to be available in the JAX-RS spec, but maybe it is only if available. I haven't read the spec well enough.

JAX-RS is iffy here.  Since it mentions @Context injection for request/response, it does leverage Servlet spec.  However, it doesn't require running on a servlet container.  I think we should call out that Servlet is part of Microprofile at some point to help alleviate this confusion.

[Alasdair Nottingham]

>
> Truth be told, even Hammock supports multiple port bindings. However, only one port is considered the application port. Other ports are more or less unmanaged, so for me those ports wouldn't be considered in this use case. However, Microprofile still doesn't describe what deployment means. Does Liberty maintain the notion of a primary port, or primary binding? And would that be satisfactory for this use case?
>

Liberty has the concept of a default http endpoint, but if you deploy multiple war files you can map each war to a different http endpoint.

Thanks
Alasdair

[Ondrej Mihályi]

Again, I would stress that we don't need to go into details here. I wanted to express that I find value in standardization, but probably on top of the config spec. We can elaborate later what can makes sense to standardize.

Going into details, I can always see a way how to support standard conf properties, and still not do any breaking change. In case of http port, if a container has a notion of a default port, than it can expose it in a standard way, why other ports would be exposed in a non-standard way or not at all. If there's no default port in the container, it could just pick a random port or the port with the smallest number to make it deterministic, whatever. I don't see how this would break things.

But maybe we can find a better solution to exposing ports than has been proposed, e.g. by exposing ports as a list. And maybe it makes no sense to standardize a property for a port number, but it makes sense to have a common property for context root, which should be the same even if multiple ports or network interfaces are used.

Using standard properties to configure the container was just my vision, I didn't want to scare you :) But I didn't originate this idea, I heard it a couple of times from different people.Most notably, when David Blevins spoke about service interoperability from an ops point of view, he envisioned that ops would be able to configure services with the same configuration and just swap service implementations like lego bricks.

--Ondrej

[Ondrej Mihályi]

Hi John,

 

JAX-RS is iffy here.  Since it mentions @Context injection for request/response, it does leverage Servlet spec.  However, it doesn't require running on a servlet container.  I think we should call out that Servlet is part of Microprofile at some point to help alleviate this confusion.

It's true that JAX-RX is iffy, but clear to understand. It states that servlet-defined types have to be injected only in case of a servlet-based implementation:

Section 10.1 of JAX-RS 2.0: "A Servlet-based implementation MUST support injection of the following Servlet-defined types: " and the list follows, including HttpServletRequest.

Section 10.3 states: "Other container technologies MAY specify their own set of injectable resources but MUST, at a minimum, support access to the types of context listed in Section 9.2." where section 9.2 defines JAX-RS specific contexts

Therefore it's clear that if MicroProfile doesn't enforce servlets, than servlet-defined types are not available in all MP-compatible containers. I don't think it's a good idea to bring in servlet spec just for the sake of these servlet-defined types. we may create a proposal to include Servlet API and collect reasons to do that, but this sole reason is just not enough IMHO.

However, we might easily expose some information that's provided by servlet API as config properties.

--Ondrej

[John D. Ament]

On Friday, April 7, 2017 at 11:34:15 AM UTC-4, Ondrej Mihályi wrote:

Again, I would stress that we don't need to go into details here. I wanted to express that I find value in standardization, but probably on top of the config spec. We can elaborate later what can makes sense to standardize.

Going into details, I can always see a way how to support standard conf properties, and still not do any breaking change. In case of http port, if a container has a notion of a default port, than it can expose it in a standard way, why other ports would be exposed in a non-standard way or not at all. If there's no default port in the container, it could just pick a random port or the port with the smallest number to make it deterministic, whatever. I don't see how this would break things.

I was thinking about this a little bit more.  You could, in theory, create a ConfigSource that was seeded based on the classloader, returning values relevant to that classloader.  This may effectively give you per-deployment configuration.

[John D. Ament]

I've submitted a PR to introduce this for MP 1.1

https://github.com/eclipse/microprofile-evolution-process/pull/23

Please review/provide input.  Please note - I don't want this PR to turn into the actual spec.  That should happen once we agree that we want the feature.

John

[Mark Struberg]

While this is an interesting idea, I think it is a tad too much change for mp-1.1.

We should keep an eye on this for later versions, but that might turn out to be quite some change to some servers. Too much for 1.1

just my $.02

LieGrue,

strub

[Emily Jiang]

I think this can be treated as a separate extension on config. We can discuss further on this PR and define the scope. If we can easily convert to a manageable issue under config, we can create an issue to track it. However, right now, we should discuss it further and find a way that our application servers can cope with.

Emily

[John D. Ament]

Originally when I was thinking about this, I had assumed that config properties were the right way to go.  However, I'm not convinced.  I've been prototyping with a "MicroprofileRuntime" class that encapsulates these values in a read only fashion, and by default in a way that is clearly scoped to an application.  This may help solve the IBM and Payara problems raised in this thread.

John