eclipse / jnosql

Eclipse JNoSQL is a framework which has the goal to help Java developers to create Jakarta EE applications with NoSQL.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support to Eclipse Config

otaviojava opened this issue · comments

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

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

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

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

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.

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

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.

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.

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

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?

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

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