[Vote] Fault Tolerance depends on Config API (soft/hard)

[Emily Jiang]

Further to the discussion of configuring FT properties, I would ask people's opinion on FT's dependency on Config API. We have the following two choices:

1. FT purely depends on Config API

This means that its properties can only be configured with the support of Config API. If a runtime does not support Config API, the FT properties, e.g.Retry.maxRetries  cannot be configured.

2. FT optionally depends on Config API

When both Config and FT are supported, the configuration can be done via Config sources. If Config API is not supported, the configuration is done via system properties.



Emily

[John D. Ament]

Option 1.

[Ken Finnigan]

I'd prefer Option 2 as it provides implementors with flexibility.

--
You received this message because you are subscribed to the Google Groups "Eclipse 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/74a59760-bfc9-45b4-b588-23f60410faad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Sutter]

Interesting.  It seems that a similar discussion happened when Config was asking whether to depend on CDI and the answer was a resounding "yes, declare the dependency on CDI".  But, so far, we have a split vote with two quite active members of the community...

I'll break the vote for now...  I vote with John on Option 1.  Since Config is part of the MicroProfile definition, then depending on Config should be a viable option.

If it comes down to what's doable for a FT 1.0 release, then I'd go the simpler route with the ability to add the alternate route in a later release.  And, wait for customer input on the additional capability.

Thanks, Kevin

[Ken Finnigan]

For me those are very different things that can't be compared.

We've said MicroProfile is part of CDI, so therefore is available to everything at all times.

In the past some, I know Mark Little was at least one, have proposed the idea of MP.io releases not containing all specifications, and therefore it would not be possible to guarantee that all MP.io releases, or their implementations, have Config Spec present.

If we're saying that MP.io releases will only ever be an ever growing bucket of Specs, a la Java EE 7, then we can certainly choose Option 1. However, are we not heading down the same road as Java EE if we take that path?

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/1cc96814-27c9-489d-ba16-feac5c8d9c47%40googlegroups.com.

[Kevin Sutter]

Ken,

I think you meant that CDI is part of MicroProfile, right?  ;-)

In any case, I hear you about avoiding a monolithic spec that requires *everything* to use.  It was extremely difficult to mix-and-match Java EE specs because the dependencies between all of the specs.  But, if a given spec provided some critical functionality, then it was "okay" to require it and let it proliferate through out the specs.  I believe CDI falls into this camp.  Due to the capabilities provided by CDI, it was allowed to be required (and even expected to be required) by many of the Java EE and MicroProfile features.

Why isn't Config in the same boat?  Separating the configuration from the application has been a long-standing requirement of the Java EE community. Now that we have it available in MicroProfile, why shouldn't we promote it's use within the MicroProfile components?

In the general sense, I do like independent specs.  It does provide for more flexible deployments.  But, I don't want the MP components to reinvent the wheel just to stay independent.

--  Kevin

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/2gJnjKb1xiw/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAKeeVe5-yMVSpY3OVJwLcWVMaK6TUCy2MDc7pBNCp0vNSG-yoQ%40mail.gmail.com.

[Ken Finnigan]

Ah yes, back to front day I guess.

I see your point.

I will concede Option 1 as it relates to Config Spec.

However, there would need to be serious consideration for a Spec to have a hard dependency on anything other than Config.

Ken

[John D. Ament]

Yes and no.  When I read option 1 vs option 2, choosing Option 1 means the only way you can configure FT annotations right now is via MP Config.  It doesn't mean at a later point we don't introduce a feature that lets you configure FT via another config mechanism that's possibly in some other specification to come out.  

It assumes that you can configure via all of the configured config sources.  Not just Env/System Properties, as well as satisfy all converter logic that comes with it.  It should actually mean less scope for FT to specify and provide a super set of functionality.

It also doesn't preclude vendors from coming up with additional mechanisms for FT configuration.

John

[Alasdair Nottingham]

I also prefer option 1. I think it would be bad if every spec came up with its own way of doing something where there is a relevant MP spec. I know that risks creating monoliths, but I don't think it would be good for every spec to have its own way to do something. As a result I think the FT spec should specify config from the MP config spec, if that can't be contained then leave config for FT out for the first release. That wouldn't preclude implementations having their own solution. 

Alasdair Nottingham

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@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/f892944d-f090-4cf3-b17f-bc79797bb923%40googlegroups.com.

[Antoine Sabot-Durand]

One of the recurring critics towards Java EE is the lack of consistency in programming model and having each specs that reinvent their own config, DI, lifecycles, etc...

Allowing each spec to have its config may lead us to go back to these critics that cripple user experience in Java EE.

That's why I vote for 1) or at least on enforcing the same way to define configuration (system properties with a common name schema) for spec that would like to not depend on config.

Antoine 

[Emily Jiang]

Option 1 clearly is the winner.

Thanks John, Ken, Kevin, Alasdair and Antoine for sharing your thoughts!

Let's see whether we can push this into FT 1.0 in the next two days. If not, in the first release of FT 1.0, we will stick with System properties. In FT 1.1, we will widen this configuration to all config sources. As system properties or environment variables are all default config sources, the apps written for FT 1.0 will continue working in FT1.1.

I think we have a ultimate goal with  a backup plan:o.

Emily

[sst...@redhat.com]

I would go for 1, and in general, if a feature has a significant configuration component there has to be a description of how to accomplish that with the Config feature. I would expect that features start defining their own config source/pojo mapping customizers as well.

I do agree with Ken that in general there should not be a requirement for all features in a given implementation of an MP release.

[Alasdair Nottingham]

Based on this thread I would be surprised FT 1.0 did config based on system properties. That sounds like doing option 2 to me. 

Alasdair Nottingham

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@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/8e6a518c-197f-44a7-ac6f-e7dbc598e6b7%40googlegroups.com.

[John Clingan]

Ack. This is bringing up the interesting question - is MicroProfile a platform or not? IMHO, yes, otherwise we wouldn't have been versioning the top-level MicroProfile specification at all. It's a forcing function to provide a consistent programming model across all specifications.

[Kenji Kazumura]

I'm curious about how we resolve the version dependencies.

Assume FT 1.0 depends on Config 1.1, and MP 1.2 includes FT 1.0 and Config 1.1.

When Config 1.2 comes up, we need FT 1.1 which depends on Config 1.2.

So we cannot release MP 1.3 until FT 1.1 is done.

Or, do we need that Config 1.2 must not break the compatibility for FT 1.0 ?

[Kevin Sutter]

I agree, Alasdair.  The clear "winner" of this vote and discussion was Option 1.  So, Fault Tolerance should provide configuration via the Config API first, followed by System Properties if it becomes a requirement down the road.

--  Kevin

On Tuesday, August 29, 2017 at 10:21:23 AM UTC-5, Alasdair Nottingham wrote:

Based on this thread I would be surprised FT 1.0 did config based on system properties. That sounds like doing option 2 to me. 

Alasdair Nottingham

On Aug 29, 2017, at 5:55 AM, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

Option 1 clearly is the winner.

Thanks John, Ken, Kevin, Alasdair and Antoine for sharing your thoughts!

Let's see whether we can push this into FT 1.0 in the next two days. If not, in the first release of FT 1.0, we will stick with System properties. In FT 1.1, we will widen this configuration to all config sources. As system properties or environment variables are all default config sources, the apps written for FT 1.0 will continue working in FT1.1.

I think we have a ultimate goal with  a backup plan:o.

Emily

On Tuesday, August 29, 2017 at 1:52:53 PM UTC+1, Antoine Sabot-Durand wrote:

One of the recurring critics towards Java EE is the lack of consistency in programming model and having each specs that reinvent their own config, DI, lifecycles, etc...

Allowing each spec to have its config may lead us to go back to these critics that cripple user experience in Java EE.

That's why I vote for 1) or at least on enforcing the same way to define configuration (system properties with a common name schema) for spec that would like to not depend on config.

Antoine 

 

On Tuesday, August 29, 2017 at 12:27:53 AM UTC+2, Emily Jiang wrote:

Further to the discussion of configuring FT properties, I would ask people's opinion on FT's dependency on Config API. We have the following two choices:

1. FT purely depends on Config API

This means that its properties can only be configured with the support of Config API. If a runtime does not support Config API, the FT properties, e.g.Retry.maxRetries  cannot be configured.

2. FT optionally depends on Config API

When both Config and FT are supported, the configuration can be done via Config sources. If Config API is not supported, the configuration is done via system properties.



Emily

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[Kevin Sutter]

Kenji,
We should be striving for backward compatibility.  But, that may not be doable in this iterative, innovative environment.  If we find something in Config 1.1 that is wrong and it needs to be corrected, then we will have a breaking change in Config 1.2.  We are not a standard (yet) and, thus, a breaking change may have to be part of the equation.  Let's not plan on breaking changes though...

To that end, in general, Config 1.2 should be backwards compatible with Config 1.1.  And, thus, FT 1.0 should be workable with either Config 1.1 or Config 1.2.  And, actually, FT 1.0 may state a dependency on Config 1.0.  So, any of them should work with FT 1.0.  But, if Config 1.2 includes a breaking change with Config 1.1/1.0, then a new version of FT 1.1 would be required to state the new dependency.

-- Kevin

[Emily Jiang]

As mentioned in the earlier email exchanges, system properties are default config sources for config api. Using system property does not mean ignoring config api. Anyway, we are trying to do option 1. Instead of limiting to system properties, we just say config properties as defined by Config specification, which automatically include system properties, environment variables and any configured config sources.

Emily

[Emily Jiang]

Good discussions! +1 on Kevin! While we strive for back compatibility, we should review the break changes seriously but we should not limit ourselves.

By the way, FT's dependencies on Config is very delicate. FT APIs does not directly depend on any Config APIs. The Config APIs are only used by FT implementors (invoking ConfigProvider.getConfig and call config.getValue). It is implementors' responsibility to make sure FT 1.0 to work with Config 1.1 and future Config specs. It is feasible.

p.s. The Config APIs ConfigProvider.getConfig and config.getValue will be very very unlikely to change in the future.

Emily