MP-Config 1.2.1: releasing a Config questions

[Laird Nelson]

Hello; I had several questions about ConfigProviderResolver#releaseConfig(Config), and, by extension ConfigProviderResolver#registerConfig(Config, ClassLoader).

The specification says, in part:

"A factory method ConfigProviderResolver#releaseConfig(Config config) to release the Config instance. This will unbind the current Config from the application. The ConfigSources that implement the java.io.Closeable interface will be properly destroyed. The Converters that implement the java.io.Closeable interface will be properly destroyed."

Does "The ConfigSources that implement the java.io.Closeable interface will be properly destroyed" mean the ones that Config#getConfigSources() returns, and only those?  I assume so.

Does "The Converters that implement the java.io.Closeable interface will be properly destroyed" mean the Converters implied, but not required anywhere in the specification, to be part of the Config, and only those?  If so, given an arbitrary Config supplied to this method, how can my ConfigProviderResolver implementation access them (there's no getConverters() method on a Config, nor is there any requirement I can find for a Config to actually use Converters)?

Should Config be required to implement Closeable?

Thanks,

Best,

Laird

[Mark Struberg]

Hi Laird!

The Config is created by the ConfigProvider so to say. So it knows all it's Converters and ConfigSources. And all those will be properly closed. 

> Should Config be required to implement Closeable?

You mean java.io.Closeable? No that is just for IO. 

If you mean AutoCloseable then I'd say that is also counter productive. Because the Config is not created 1 per usage but it is a 1-per-Application. 

It's by default very similar to CDI @ApplicationScoped. So closing it after each usage would not be a good idea as it will render the Config unusable for later.

LieGrue,

strub

[Laird Nelson]

On Saturday, March 31, 2018 at 12:21:19 PM UTC-7, Mark Struberg wrote:

The Config is created by the ConfigProvider so to say. So it knows all it's Converters and ConfigSources. And all those will be properly closed. 

Er, how, exactly?  Suppose you are implementing the releaseConfig(Config) method.  And suppose I hand your method a Config.  How will you access its internals to close them?  You can get its ConfigSources by calling getConfigSources.  But there's nothing on the Config interface to require that a Config even use Converters.  In fact the specification does not say that a Config has to use them.  But the specification does say that Converters of some variety must be closed (presumably the ones it is assumed a Config uses) if they implement Closeable, so I'm trying to figure out how a releaseConfig(Config) implementation would accomplish this, given an arbitrary Config.  Thanks!

Best,

Laird

[Mark Struberg]

Oki what we like to miss here is that the `Config` you can pass in to releaseConfig *must be* a Config you get from the underlying mp-config implementation. 

So the implementation can safely upcast to it's own impl.

LieGrue,

strub

[Laird Nelson]

On Tuesday, April 3, 2018 at 2:52:56 PM UTC-4, Mark Struberg wrote:

Oki what we like to miss here is that the `Config` you can pass in to releaseConfig *must be* a Config you get from the underlying mp-config implementation. 

Eek; that's a rather…strange API restriction, but I'm glad to see that indeed there's no obvious way to implement the specification given an arbitrary Config.  Seems like it would be much better if Config implemented Closeable with some defined behaviors.

Also, please note that there is nothing in the public API that indicates that a Converter ever be used for anything.  All Config#getValue(String, Class) has to do is ensure that given a String value, a value of the appropriate type is returned.  Personally, I like it this way; my belief is that conversion should be an aspect of a ConfigSource to prevent the non-portability-of-configuration-artifacts problem I've previously brought up in this group.  If it were, then conversion should be entirely up to the implementation.

Best,

Laird

[Mark Struberg]

Converting is not an aspect of `ConfigSource`but an aspect of the overall `Config`.

The `ConfigSource` is strictly String/String based.

LieGrue,

strub

[Laird Nelson]

On Monday, April 9, 2018 at 3:03:50 PM UTC, Mark Struberg wrote:

Converting is not an aspect of `ConfigSource`but an aspect of the overall `Config`.

Right; I definitely understand that that is how the specification models it.

I'm saying that's an unfortunate mistake and a shame IMHO, because it means that now in application server A there may be a Converter<URL> (for example) that converts Strings into URLs in a manner different from that used by the particular Converter<URL> present in application server B, so my configuration artifact (my properties file, represented by a ConfigSource) is not portable between A and B.  A, in other words, may understand my properties file, but B may not, and that's permitted by the specification.  Or, to put it one final way, I have to understand at a possibly deep level all the configuration-related differences between application server A and B in order to ensure my properties file can be understood by both of them.

Best,

Laird

[Emily Jiang]

Hi Laird,

I am not quite understand the difference between the Converter<URL> among application servers. URL is an implicit converter. All application servers will rely on the class URL directly to provide a converter. For application specific converters, the converters will be provided by the applications, so I don't see any portability issues.

Emily

[Laird Nelson]

On Monday, April 9, 2018 at 1:50:34 PM UTC-7, Emily Jiang wrote:

Hi Laird,

I am not quite understand the difference between the Converter<URL> among application servers. URL is an implicit converter. All application servers will rely on the class URL directly to provide a converter. For application specific converters, the converters will be provided by the applications, so I don't see any portability issues.

Hi, Emily; here is the scenario.

I am thinking of two environments, A and B.  A looks like this:

There is a MicroProfile-Config 1.2.1 implementation on the classpath.

There is a jar, u, containing a Converter<URL> implementation as a service provider on the classpath with a priority greater than 1 that parses Strings of the form "url<http://example.com>" into URL instances.

There is a ConfigSource, cs, that reads (making this up) /META-INF/urls.properties resources.

The jar that contains cs contains a file /META-INF/urls.properties (p).

An entry in p looks like this: production=url:<http://example.com>

B looks like this:

There is a MicroProfile-Config 1.2.1 implementation on the classpath.

u (see above) is not on the classpath so there is no non-default Converter<URL> on the classpath, i.e. the default one is used.  (That means it parses Strings of the form "http://example.com" into URL instances.  It has a priority of 1.)

cs (see above) is on the classpath.

Suppose an application deployed to both A and B does config.getValue("production", URL.class).

In environment A, everything works fine.  In environment B, it does not.

So the configuration author—the person who wrote the url.properties file—has to know whether her work will be processed by the default URL converter or not.  That means she has to know in advance what kind of environment she is deploying her work to.  That seems odd.

Best,

Laird

[Alasdair Nottingham]

I don’t understand the scenario. Both the Converters and the ConfigSources are pluggable, for url.properties to be ready you have a mechanism to package your ConfigSource for both scenarios. Why can’t you package the Converter in the same way as the ConfigSource so it can do the conversion for you?

Alasdair

--
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/2ce9c369-384a-489d-96e7-e42372eaa522%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Emily Jiang]

Alasdair was correct. For your scenario, environment A and B just provides MP Config 1.2.1 not other converters except the default or implicit converters. The converters or config sources provided by the apps are in the app. If you don't alter your app between environments, the app is portable. If you have two different apps, portability is orthogonal.

Thanks
Emily

[Laird Nelson]

On Monday, April 9, 2018 at 3:53:16 PM UTC-7, Alasdair Nottingham wrote:

I don’t understand the scenario. Both the Converters and the ConfigSources are pluggable, for url.properties to be ready you have a mechanism to package your ConfigSource for both scenarios. Why can’t you package the Converter in the same way as the ConfigSource so it can do the conversion for you?

Because wouldn't that impact someone else's properties file on the classpath that doesn't happen to use the formatting mine does?

Best,

Laird 

[Alasdair Nottingham]

You could equally write your ConfigSource so it removes the url<> from around the url so the ConfigSource would return http://example.com rather than url<http://example.com> 

Alasdair

--
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/0f39d501-2a9d-4f21-b7b4-db59faaa04c3%40googlegroups.com.

[Laird Nelson]

On Tuesday, April 10, 2018 at 10:06:27 AM UTC-7, Alasdair Nottingham wrote:

You could equally write your ConfigSource so it removes the url<> from around the url so the ConfigSource would return http://example.com rather than url<http://example.com> 

That's true; it was just an example.  The point is that String-to-Object conversion is always convention-based, and with this specification if such conventions are mixed—i.e. if one is introduced into an ecosystem that features another—otherwise happy coexisting applications may break.  It appears that deployers need to make sure that they know the ecosystem they are going to deploy their configuration artifacts into in advance, and adopt the prevailing convention, which is a strange caveat from a specification standpoint.  Simply requiring that a ConfigSource manage conversion with respect to its own artifacts would fix this, but I understand that train has left the station; I mainly just wanted to call attention to the issue.  All of this can be worked around and documented in the real world, of course.

Best,

Laird

[Emily Jiang]

Laird,

The environment does not provide any other converters except default converters. I don't quite get the ecosystem scenario. When you write application, the application needs to provide the converters and non-default config sources it needs and it should not rely on any application server adds on. If it does, it is guaranteed this app is not portable. I think it makes sense. By the way, in your example of A and B, the apps deployed are two different apps (as the structure differs).

Thanks

Emily

--
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/-uxdjxFdifE/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/836a7749-576a-4ddc-a54b-91fecc58e816%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Thanks
Emily
=================
Emily Jiang
eji...@apache.org

[Laird Nelson]

On Tuesday, April 10, 2018 at 2:58:53 PM UTC-7, Emily Jiang wrote:

The environment does not provide any other converters except default converters. I don't quite get the ecosystem scenario. When you write application, the application needs to provide the converters and non-default config sources it needs and it should not rely on any application server adds on.

OK.

 

If it does, it is guaranteed this app is not portable. I think it makes sense. By the way, in your example of A and B, the apps deployed are two different apps (as the structure differs). 

OK.  Thanks for your time.

Best,

Laird

[Laird Nelson]

On Monday, April 9, 2018 at 3:53:16 PM UTC-7, Alasdair Nottingham wrote:

Why can’t you package the Converter in the same way as the ConfigSource so it can do the conversion for you?

Here is more focused scenario that I think is more realistic and will (I hope!) make my concern more clear.

Suppose I am putting together a MicroProfile application.  And suppose as part of putting this application together I would like to use two third-party CDI extensions from vendors A and B that are, themselves, MicroProfile-Config aware, i.e. they use MicroProfile Config themselves to look up configuration information.  So I include these extensions in my application.

Let's say that A's extension allows my application to inject a Redis client (arbitrary; making this up) and B's extension allows me to inject a Cassandra client (arbitrary; making this up).  Let's further suppose that both extensions need URL information: A's needs it so that it knows where Redis is, and B's needs it so that it knows where Cassandra is.

Let's say that A packages a Converter<URL> with a priority of 100 that knows how to turn Strings of the form "example.com:6379" into URL instances.

Let's say that B packages a Converter<URL> with a priority of 101 that knows how to turn Strings of the form "jdbc:cassandra://example.com:9160/system?version=3.0.0" into URL instances.

Let's say that -D"redisUrl=example.com:6379" and -D"cassandraUrl=jdbc:cassandra://example.com:9160/system?version=3.0.0" were passed on the command line.

So A's extension does config.getValue("redisUrl", URL.class) in order to produce a URL and B's extension does config.getValue("cassandraUrl", URL.class) in order to produce a URL.

What happens?

My understanding is that the Converter<URL> packaged with B, which has the highest priority, will be used to convert both example.com:6379 and jdbc:cassandra://example.com:9160/system?version=3.0.0. The attempt to convert example.com:6379 will fail; the attempt to convert jdbc:cassandra://example.com:9160/system?version=3.0.0 will succeed.

My further understanding is that the ways to fix this problem include patterns like:

• Urge vendor A and vendor B to rely on implicit conversion and wait for them to deliver new extensions that don't use their own converters.
  
• Write my own Converter<URL> that handles both formats and edit /META-INF/services/org.eclipse.microprofile.config.spi.Converter files as appropriate to make sure that only mine is the one that's used.
  

Is that correct?  Are there others?

The part that is concerning to me is that I need to understand when I package these extensions together that this problem will arise, but it seems to me that I won't know that there is a problem until I try to run my application.  I'm probably missing something again!

Thanks very much for bearing with me as I try to understand these scenarios.

Best,

Laird

[Emily Jiang]

Hi Laird,

Thank you for spending time to explain the use case! I do understand this problem now.

In this scenario, when you use lib A and B, obviously you will need to understand them that they provide URL converters. When you put the app together, if you want to fix the issue you are experiencing, you can create another converter having a higher priority than the two and then try to invoke lib A's URL converter first, followed by lib B's converter.

We did discuss in the past to do a chained converter. e.g. Gather the same type converters and order them according to their priority. Feed in the string to convert to the desired object till the success or running out this type converters.

Please feel free to raise an issue on microprofile-config repo to ask for this capability.

Thanks
Emily

[Laird Nelson]

On Friday, April 13, 2018 at 10:28:32 AM UTC, Emily Jiang wrote:

Thank you for spending time to explain the use case! I do understand this problem now.

Ah, good; I was worried I was really misunderstanding something.

 

In this scenario, when you use lib A and B, obviously you will need to understand them that they provide URL converters.

Right; I think that's a problem for real-world messy enterprise development where people will (ultimately, hopefully) be using lots of MicroProfile-Config aware pieces in their application.

 

When you put the app together, if you want to fix the issue you are experiencing, you can create another converter having a higher priority than the two and then try to invoke lib A's URL converter first, followed by lib B's converter.

Right.

 

We did discuss in the past to do a chained converter. e.g. Gather the same type converters and order them according to their priority. Feed in the string to convert to the desired object till the success or running out this type converters.

Yes, that would be one way to proceed, but would involve converters doing unnecessary work.

I'm wondering if a better solution might simply involve ranking Converters that are packaged with ConfigSources higher than those that aren't.  If you ship a ConfigSource and a Converter<URL>, then your Converter<URL> will be preferred over those that might otherwise be present on the classpath.  WDYT?

Best,

Laird