Support to Eclipse Config

[otaviojava]

This proposal has the goal to work to support Eclipse JNoSQL:

@Inject
@ConfigProperty(name = "name")
private ColumnFamilyManager manager;

• https://www.eclipse.org/community/eclipse_newsletter/2017/september/article3.php
• https://github.com/eclipse/microprofile-config/blob/master/spec/src/main/asciidoc/converters.asciidoc

[otaviojava]

That one’s interesting. I like MicroProfile config, but I’ve only seen and used it so far in basic cases for primitives and Strings. If we can implement that in a way that makes idiomatic sense and doesn’t seem shoehorned in, that’d be great by @jesse-gallagher

[keilw]

As this is an implementation project I guess it is a safe approach to start e.g. using the MicroProfile API and annotations and if it evolved into a Jakarta EE spec use that.

Do you envision any similar needs for the NoSQL spec? As it could be problematic to use MP config there, but in the JNoSQL project it seems fine. Also see #115

[otaviojava]

I'm glad to start the discussion; my first question is:
Once we're working on Jakarta NoSQL can we make any Eclipse MicroProfile dependency as a requirement?
Until now, it is uncertain how Eclipse MicroProfile and Jakarta EE will work together.
My first idea is to work it as an extension in the Reference implementation, so it will not involve the API itself.

[otaviojava]

To put more context, in the configuration we have five mandatory fields:

• The name: the name of the configuration, it works as an ID
• description: a description of the configuration, it won’t be used
• provider: the classpath of a configuration implementation.
• settings: the entry list, as a Map, to be used when it creates the instances.

Unlike either JSON or YAML properties file does not support array settings, therefore, the settings in the file must be enumerated.
My suggestion is the name attribute in @ConfigProperty works as a suffix in the configuration. So, given the entity:

@Inject
@ConfigProperty(name = "suffix")
private ColumnFamilyManager manager;

The configuration will be:

#required fields
suffix.provider=org.eclipse.jnosq.NoSQLProvider
#optional field
suffix.description=that is the description
#optional settings
suffix.settings.0=a configuration
suffix.settings.1=a second configuration
#only for Template class, Communication manager, Repository class
suffix.database=database

Ref: http://www.jnosql.org/spec/#_configurationunit

[keilw]

I don't think a Jakarta EE specification (API) could use a non-standard project like MicroProfile or Spring in its code. Ask e.g. @waynebeaton to confirm, because he's both a mentor to Jakarta NoSQL and MicroProfile, but from my understanding the spec cannot use @ConfigProperty as long as it isn't defined by a Jakarta specification. It can use @Inject which already is.
For Eclipse JNoSQL as long as there are no license conflicts, I see no problem using either or something else like Apache Commons Config, DeltaSpike, etc.

[otaviojava]

Hey @keilw that why I've created this issue in Eclipse JNoSQL, the reference implementation. I believe they are going to have this kind of discussion in the future.

[otaviojava]

Hey Guys, this week is happening Oracle Code One, and we have opportunity to talk about this with several people. Some information:

• There is no way, at least yet, to put Eclipse Config into Jakarta EE spec.
• One good recommendation is to remove the ConfigurationUnit annotation once these two specifications to work with it:
  * https://github.com/eclipse/microprofile-config
  * https://www.jcp.org/en/jsr/detail?id=382
• We can start to create a module project to test this project integrated with Eclipse Config as part of the Reference Implementation.

[otaviojava]

Eclipse MicroProfile Proposal

Each configuration has four information:

• name: the name of the configuration, it works as an ID
• description: a description of the configuration, it won’t be used
• provider: the classpath of a configuration implementation.
• settings: the entry list, as a Map, to be used when it creates the instances.

In JSON it will be like:

{
     "description":"that is the description",
     "name":"name",
     "provider":"class",
     "settings":{
        "key":"value"
     }
  }

The proposal is to convert it to properties on Eclipse Config. The plan is to use the value to name at the ConfigProperty annotation as prefix configuration; therefore given the annotation :

@Inject
@ConfigProperty(name = "database")
private ColumnFamilyManager manager;

The configuration should be on that structure:

database=prefix
prefix.description=that is the description
prefix.provider=org.eclipse.jnosql.provider.MyClass
prefix.settings.key=value
prefix.settings.key2=value2

@Emily-Jiang @keilw what do you think about that structure?

[otaviojava]

I created a PR to remove the ConfigurationUnit from the Spec and then to use the Eclipse MicroProfile Configuration in the Reference implementation:

• Support to Eclipse Config #203  #210
• Removes Configuration annotation jakartaee/nosql#28

[keilw]

Guess that's all we can do for now, if someone proposes a Jakarta Config spec some day we might change it.