Principal Issue

[marcelosv]

Introduction

In my experiences in developing microservices, I like to use the 12factor pattern, developed by the community.

https://12factor.net/

"The contributors to this document are directly involved in the development and deployment of hundreds of applications, and indirectly witnessing the development, operation and escalation of hundreds of thousands of applications through their work on the Heroku platform."

"This paper synthesizes all of our experience and observation into a variety of software-as-a-service applications. This is the triangulation of ideal software development practices, with particular attention to the dynamics of organic growth of an application to the software. over time, the dynamics of collaboration between developers working on a code base, and avoiding the costs of software erosion "

The "III. Settings" item talks about the application settings.

https://12factor.net/config

"Applications sometimes store the settings in the code as constants.This is a twelve-factor violation, which requires a strict separation between configuration and code.Configuration varies substantially between deploys, not code."

It is interesting to note that in the text itself it says that settings that never change, can be inside the application, without problems. But settings that are environment-friendly, need to be separate.

Why use Server Config in Juneau?

Using rule III as the default, we need to have a way to have an external configuration of the system settings. Important also for the server, it will be implemented a way of being able to the application to look for new configurations and to change its environment, without needing to restart the application.

For this we will need 3 main items.

1. A server where it will be used to load the settings. Let's use GIT as repository. This server will have an endpoint that we will call to fetch the settings. EX:

curl http://localhost:8080/{application}/{branch}/

2. We will need a client, where we will use it in the applications, so they can call the server and get their settings.

Organization of the repository

// in this file account generic settings for all applications
application.properties

// each application will have its own prop file
application1.properties
application2.properties

What happens when a configuration has in application.properties and in application1.properties?

There will be a hierarchy because they can now have a repeated configuration on the server and within the source code.

Initially the order would be this:

1. Command line. ex: java -jar XXX -Dconfig = 1
2. Application file in server config. ex: application1.properties
3. Generic file in server config. ex: application.properties
4. Local file within code

Roadmap for development

1. Server Config

   • [ ] Define subproject name; https://github.com/marcelosv/juneau/issues/2
   • [ ] Create the project; https://github.com/marcelosv/juneau/issues/3
   • [ ] Define a git library to use; https://github.com/marcelosv/juneau/issues/4
   • [ ] Create the ENDPOINT that receives "application name" and "branch"; https://github.com/marcelosv/juneau/issues/5
   • [ ] Define the JSON that the server will return. It must be a list; https://github.com/marcelosv/juneau/issues/6
   • [ ] Create the service that consults from the git repository and with the received branch, organizes the settings with the settings of the application.properties and the application that was sent. https://github.com/marcelosv/juneau/issues/7

2. Server Config Client

   • [ ] Define subproject name; https://github.com/marcelosv/juneau/issues/8
   • [ ] Create annotation to enable operation from within the application; https://github.com/marcelosv/juneau/issues/9
   • [ ] Create 2 keys to be able to identify where the server config is; https://github.com/marcelosv/juneau/issues/10
   • [ ] Create service that when uploading the server, it calls the server config to search its settings; https://github.com/marcelosv/juneau/issues/11
   • [ ] Create an implementation of the configuration, which provides hierarchy in the configuration and that when giving the get in a configuration, it looks for the correct configuration; https://github.com/marcelosv/juneau/issues/12

[jamesbognar]

Some questions:

1. The Config API used to (a long time ago) have the concept of config imports. For example, the following would allow you to import values into a config: %CommonSettings% This was lost during the last refactoring, but it could be reintroduced if it would be helpful in defining hierarchies. The tricky part is properly handling listener events on parent configs. For example, if a setting in a parent config changes but it's overridden in an child config, you don't want to trigger a change event.

2. Do you know if Git provides its own notification mechanism for file changes? If so, it could be used to trigger calls to ConfigStore.update(...) method to automatically trigger change notifications. Ideally a change to a config file in Git would trigger notifications to all endpoints without the need for polling. This would require some sort of client/server registration though (the client would have to provide the server with a REST endpoint to be called to notify the client of any changes).

[Akayeshmantha]

Hi @marcelosv this looks awesome.Will it be possible to have a task for us to work on gsoc 19. Me and @shalitha thought to work on gsoc internships.So since we have worked with juneau we thought it would be greet to work with apache juneau.