jakartaee / config Goto Github PK

As an application deployer, I expect that the deployed application and/or its frameworks have the ability to recognize configuration changes at run time and deal with them in some manner that maintains application integrity, so that I can update certain configuration values without having to restart the application.

Source: #27 (comment)

As an application or framework developer, I expect that there will be a way to provide support for additional configuration store(s) so that I can provide configuration properties from run time environments (such as K8s secrets, vaults, etc.).

Source: #27 (comment)

As a component developer, I want to be in charge of what to do when configuration property is missing eg.: I want to be informed when a configuration property is missing, and I may choose to do any of the following: throw an exception, substitute some other value, or perform some other action in response.

As an infrastructure component developer who is implementing a dependency injection system, I want to retrieve an object representing my dependency injection system's configuration in such a way that the dependency injection system is not required to be (circularly) involved.

Like Oracle Helidon SE, provides a simple Config to load the config by programmatic approaches.

Config config=Config.create(); // provides alternative to customize the source, converters, etc.

String hostname=config.get("hostname");
int port=config.get("port");

Hi,

I’m a member of the Eclipse Foundation Security Team. I’ve analyzed this repository with Scorecard and StepSecurity to check if it was applying some supply chain security best practices.

The following issue(s) has(ve) been detected:

• Apply least privilege principle to GITHUB_TOKEN in GitHub workflows for files .github/workflows/build.yml
• Pin Actions to a full length commit SHA for files .github/workflows/build.yml

As a result, you will see some PRs coming both from me and/or the StepSecurity bot to provide fixes for those issues. This issue will serve as the parent for those PRs.

Thanks!

Francisco Perez

In a ConfigurationProperties bean described in #19, allow add bean validation annotation to validate the config by parsing/loading time.

As an app developer, I want to be able to discover changes in configuration to be able to update my component with such a changed configuration.

As an application or framework developer, I expect there to be an easy way to utilize provided additional configuration store implementations so that I can minimize the amount of labor necessary to do so.

Source: #27 (comment)

According to javadoc and location the ConfigProviderResolver class is intended for implementors of Jakarta Config, as the main entry point. ConfigProvider is then the main entry point for a user.
ConfigProvider only allows user to get hold of a Config instance, but does not have any support for more advanced use cases (such as registration of config, creating a new config using a builder).

It may be useful to create static methods on ConfigProvider, so end user never needs to use ConfigProviderResolver class.

e.g.:
ConfigProvider.newBuilder()
ConfigProvider.register(Config config)

As an operations person, I want a way to define parts of the config whose values will not printed out in clear text but only as e.g. '**********' Sometimes config is also used for critical information like secret data which must not show up in logs etc.

As an application developer or admininistrator, I want to see where my config value is serving from so that I can update the value in the right config source.

As an application developer, deployer or tester or a framework developer or tester, I expect to be able to specify that a configuration property should be removed in the event that it would otherwise have a value, so that I can easily make necessary adjustments to the configuration at deployment or testing time.

Based on #27 (comment) with some modifications

As a configuration file author, I want to have a means to know what configuration keys will be recognized, so that I can avoid errors arising from key name mistakes.

As an application developer, I want to specify config properties based on different environments (dev, prod, test, different db vendors, etc.).

As an app devleoper, I want to read a list or array of configured values of complex types. This might e.g. be a list of ServerEndpoint configs, each of them consisting of hostname, port and path

Dear committers, a slack channel config was created for Jakarta Config. I have invited the committers whose email address is available to me and the ones who are already in Jakarta EE slack workspace. When you see an slack invitation email, please feel free to join the channel.

If you have not got the invitation and would like to join, please click this link and then click on Join our Slack Workspace. Once you get into slack workspace, you will see the channel config.

The channel is for some initial brain strom or idea discussion not for decision making.

As an application or framework developer, I expect to be able to use DI mechanisms to acquire strongly-typed configuration values, so that I can easily acquire configuration relevant to the component without having to use the programmatic API.

Source: #27 (comment)

Project's mailing list has been created!

All committers, please subscribe:
https://accounts.eclipse.org/mailing-list/config-dev

To avoid IDEs automatically importing the wrong class, it might be a good idea to rename jakarta.config.NoSuchObjectException to something else. There is a class of the same name in the JDK java.rmi.NoSuchObjectException

I believe shortly that a Jakarta Configuration will be a glue to configuration such as CDI does to communicate among specifications.

It is essential to have a unique configuration for the whole specification, to get reliability, and reusability, to reduce the number of bugs, and so on.

Looking at several platforms, we have several configurations that require more than properties, such as JPA connection, NoSQL client, JMS connection, etc.

It will be terrific if we have support for a more dynamic type such as a Map<String, String>.

It uses the prefix as an injection, and then it will put a key/pair dynamically. So, given this properties:

# datasource configuration
jakarta.datasource.db-kind = postgresql
jakarta.datasource.username = hibernate
jakarta.datasource.password = hibernate
jakarta.datasource.jdbc.url = jdbc:postgresql://localhost:5432/hibernate_db
jakarta.datasource.properties.dyamic=123

Using the injection:

@Inject
@ConfigProperty(name="jakarta.datasource") 
private Map<String, String> map;

It will provide the following keys:

db-kind = postgresql
username = hibernate
password = hibernate
jdbc.url = jdbc:postgresql://localhost:5432/hibernate_db
properties.dyamic=123

A link to the meeting minutes should be added to the Communication section of the Wiki.

https://docs.google.com/document/d/12_HdTKjkO_pxfeFsjtGXCsR-EaG42fblJNagvsSMyeE/edit#heading=h.9d84otfo5ary

As an application developer or deployer or tester or framework developer or tester, I expect to be able to use system properties and environment variables to easily override configuration values so that I can easily make necessary adjustments to the (application and/or framework) configuration at deployment or testing time.

Source: #27 (comment)

As an operations person, I want to be able to overwrite/tweak certain configuration values which come as part of the application.

Otoh it should not be required to provide every configured value by the ops team. Applications must work out of the box - tweaking configuration values should only be required if really needed.

The Spec document needs to be updated:

• The @ConfigMapping -> @Configuration
• The META-INF/jakarta-config.properties source MUST be supported
• The nested interface @Configuration annotation is ignored
• ....
• Any other discrepancy currently in the Spec document needs to be aligned with the currently up-to-date javadoc

In MicroProfile, we have been using OSGi semantic versioning and it has worked very well. We need a way to properly version our APIs.

As an operations person, I want to have an easy way to read out what configured values can be tweaked by the operation team.
Having an application configurable is only the first step. Only having an ops team which can easily query which ConfigSources got picked up in which order.

As an app deployer and container administrator I want to be able to discover expected configuration options of a deployment (application). Such a discovery should allow me to read configuration keys, expected type (boolean, String), configured default value, and description.

As an application developer I want to mark mandatory configuration keys, so that if values for them are missing during startup the application will fail early and eagerly.

This is a configuration consistency check at startup.

This is a follow up to #6.

The ConfigProviderResolver class should be an interface (to provide more flexibility to implementer). The cache and service loader operations should be moved to a package local utility class used from static methods of the interface.

As an app developer and tester, I want to be able to configure empty String values in String options to access resources that may use these as semantically correct values (such as empty passwords).

Let's use this issue for discussing time slots for Jakarta Config meetings.

Since Jakarta Config mailing list is not created yet, let's use this issue for discussing time slots for Jakarta Config meetings. I created a Doodle poll here:

https://doodle.com/poll/8u2ezuf7pvksu846

I added time slots which work for me (sorry about it), but I am fine to add more slots for consideration.

As an application assembler who integrates components that may be using Jakarta Config but which I didn't develop, I want to resolve the inevitable naming clashes.

Provides a Spring @ConfigurationProperties or MP @ConfigProperties/@ConfigMapping like annotation on interface, record and POJO classes, etc. to group config properties.

@ConfigurationProperties(prefix="server")
public record ServerConfig(
    @ConfigProperty(name="protocol", defaultValue="http") //named to "protocol" and set default value to "http"
    String schema, 
    String host,
    int port
){}

As an application deployer who deploys an assembled application into some environment representing a location in configuration space, I want to ensure that if the application is deployed and started in exactly the same way twice, with no attendant changes to its configuration, it will have the same state in both occurrences, i.e. I want to ensure configuration is deterministic.

As a component developer who doesn't know what application my component will belong to, I want my component to retrieve a particular variant of an object representing a portion of my configuration.

As an app devleoper, I want to read a list or array of configured values of single values. An example would be a list of valid keys, or a list of specially handled business keys.

As a user of the configuration API and/or injection mechanisms, I expect there to be a range of default value type conversions so that I can have configuration values of common JDK value types without having to explicitly enable or implement those conversions.
Source: #27 (comment)

If, for some strange reason, you do this...

TypeToken<?> t = new TypeToken() {};

then you get

java.lang.NullPointerException: Cannot invoke "java.lang.reflect.ParameterizedType.getActualTypeArguments()" because the return value of "typetoken.TypeToken.mostSpecializedParameterizedSuperclass(java.lang.reflect.Type)" is null

Given that mostSpecializedParameterizedSuperclass is a private method which is only ever called from the constructor of TypeToken, it isn't a good idea for it to ever return null. If it does ever return null (through misuse of TypeToken), the result will be a generic NPE rather than an specific exception with a helpful error message.

Suggest throwing some flavour of ConfigException rather than returning null. The exception message can be specific to the if block which is throwing it.

Alternatively, if mostSpecializedParameterizedSuperclass can return null, put a null check in the TypeToken constructor and throw the ConfigException from there. However, at this point you will have lost some context about what the (very unexpected) problem is.

Credit to @Azquelt for spotting this issue.

As spec/api projects are being moved to GitHub/jakartaee, I wonder if the config team is ready to action this. It's a relatively simple operation, and redirects will be automatically put in place.

If the team members agree and give me permission, I can create the action bug to get this moved if needed.

In the steering committee we voted to moved all specification projects from eclipse-ee4j to jakartaee. As such this repo should move to in due time.

Moving is fairly automatic, and redirects will be automatically put in place from the current location here to the new location.

Extra from: https://www.eclipse.org/lists/jakarta.ee-spec/msg02073.html

"We voted on it in 2019 and then in 2020 we added it explicitly to our 2021 plan and voted on that plan. I think we just need to start executing. I sent about 30 emails like the following in an attempt to add some shape to it and kick off the move in the spec projects.

• https://www.eclipse.org/lists/jakartaee-platform-dev/msg02940.html
• https://www.eclipse.org/lists/messaging-dev/msg00028.html
• https://www.eclipse.org/lists/jakartaee-tck-dev/msg01417.html
• https://www.eclipse.org/lists/ejb-dev/msg00264.html
  "

Also note that many projects have indeed moved: https://github.com/jakartaee/

Currently, Jakarta Config allows for loading config into an interface

@Configuration
public interface A {
   String value();
}

The most use-cases, however, are as follows:

if (config.property('NAME1')) {
     // do something
}
if (config.property('NAME2')) {
   // do something else
}

The convenient way is to allow the possibility to load the single value as Loader.bootstrap().path("NAME1").asString().
In MP config, there is a similar notion: config.getValue("NAME1", String.class)

There are the following possibilities:

1. Allow just few methods: asInt(), asBoolean, asString
2. Allow all primitive types: boolean, byte, short, float, double, int, long, char, and String
3. Allow just asString() and more generic as(Class<T> type) and as(TypeToken type) - this has an advantage that later on the config could support as(UserDefinedType), but a disadvantage that we should define a way to pass convertors to the Loader.

The use-case usually checks whether the property is present. That can be implemented by:

1. returning null when not available
2. returning Optional<> (my favourite)
3. throwing NoSuchObjectException
4. implement a complementary isProperty()

In the case of Optional, it would be possible to use:
loader.path("my.property").asString().ifPresent(myProperty -> doSomething(myProperty))

Nice to have: As app developer, I want to read single String values without having to type a lot.

String values is a big part of configuration business. It should be easy to consume the configuration

Currently Config contains methods to access meta configuration ("ConfigConfig"), such as getConfigSources()

These methods may be confusing for end user, as they should not be used (except for troubleshooting purposes, or for some advanced use cases - @struberg, could you please share such a use case here?).

These may be moved to a separate class (and should be moved if we go with tree structure).

As an app developer and tester, I want to be able to make my config value refer to other config property.

Support the nested config in a Map or Collection under another config, depends on #19

@ConfigurationProperties(prefix= "app")
class AppConfig{
String name;
Map<ServerConfig> servers;
}

@EachProperty//micronaut provides such a feature to configure property for  every nested config, etc.
class ServerConfig (){}

As an app developer, I want to read multiple configuration values which belong together in an atomic way.

Often business logic doesn't only need a single value but multiple values which belong to each other. like a server hostname, port and path.
It should be possible to read them in a single atomic access.
If we support mutability, we need to ensure the atomic access.

As an application developer or deployer, I expect that the configuration file(s) can be found or deployed into predictable location(s), so that I can easily determine what the configuration is.

Source: #27 (comment)

Since this repo is to rehome MicroProfile Config to Jakarta EE. The first step is to create a baseline on Jakarta Config. I will create a PR for this baseline and then we can discuss to take in feedback.