Create a CDI based API for custom converters

[OndroMih]

As mentioned in #124 , there's no CDI-based way to provide custom converters. They could be provided simply by adding a producer.

In similar way, we also don't have such API for ConfigSource and ConfigSourceProvider - each class that can be loaded via Service Loader should be at least considered to be loaded from a CDI producer (unless it's already too late when CDI producers are available)

[Emily-Jiang]

@OndrejM custom converters use the same pattern as config source, which are loaded via service loader. See converter javadoc.

Why do you need a CDI-based APIs for Converters?

[OndroMih]

Service loader is not very friendly, especially when CDI is available. CDI producers are much more convenient to write than creating a service file. Developers prefer writing Java over textual files and referencing classes via full name. CDI producers are also checked at compile time, unlike service files, where it's easy to make a typo, which may often lead to hours of investigation.

[OndroMih]

Simply, as a developer myself, I would see no reason why I would want to use service loader in a CDI container.

[struberg]

@OndrejM Because the CDI container is probably not booted for a loooong time when you first access the Configuration ;)

We might have been able to go that way if we would have used the CDI-only approach (PR #40 I think) but that came with a few other drawbacks.

[OndroMih]

@struberg I understand. But my point is not to replace the service loader, but provide an alternative way to define extensions. Most users would be application developers, which already can use the CDI container for everything.

[smillidge]

I agree with Ondrej on this one. Currently ServiceLoader is somewhat limited. For example when implementing a custom ConfigSource there is no standard way of passing configuration to the ConfigSource on creation as ServiceLoader just instantiates an instance of the class. A CDI api could provide this configuration.

Configuration data is essential for a ConfigSource that talks to an external repository.

[Emily-Jiang]

ok. In MP1.1, we can investigate the producer approach to supply converters and configsource.

[smillidge]

Another option is annotation based definition similar to how JCA connectors can be deployed for example.

This doesn't have to depend on CDI but it could be specified to support ConfigProperty Injection by saying it should be created after all default config sources have been initialised so it can read its properties from default sources.

@ConfigSourceDefinition 
public FooConfigSource implements ConfigSource {

   @ConfigProperty(name="url", defaultValue="http://foo.bar.com")
   String url;

  ...  
}

[Emily-Jiang]

Use case:
As a CDI developer, I want to use producer to supply a custom converter/config source/config prividers so that service loader is not mandatory.