New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch application configuration syntax to HOCON #387

Closed
cescoffier opened this Issue Dec 10, 2014 · 5 comments

Comments

Projects
None yet
2 participants
@cescoffier
Member

cescoffier commented Dec 10, 2014

The current format is too ambiguous and does not let us support modularisation of the configuration (this is going to be another issue).

HOCON provides a less ambiguous format, with nice characteristics such as:

  • includes
  • substitution
  • inheritance
  • structuration
  • list and complex object

However switching to HOCON is a long run:

  • provide a converter to migrate existing application.conf file to the new format
  • adapt the Application Configuration implementation to use HOCON
  • migrate the configuration file all all projects
  • update documentation
  • update archetypes and project generator
  • expose first-level Configuration object as service
  • add methods to Configuration to retrieve duration, size (in bytes) and doubles
  • add method on Configuration to check whether a 'value' is present or not
  • add the base directory as a property

Some points are preparing for the configuration modularisation.

@cescoffier cescoffier self-assigned this Dec 10, 2014

@cescoffier cescoffier added this to the 0.7 milestone Dec 10, 2014

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier
Member

cescoffier commented Dec 20, 2014

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier Dec 24, 2014

Member

I've remove the injection for now (will be handle in another issue)

Member

cescoffier commented Dec 24, 2014

I've remove the injection for now (will be handle in another issue)

@magnet

This comment has been minimized.

Show comment
Hide comment
@magnet

magnet Dec 27, 2014

Contributor

Hey Clément,
Nice to see this work going, since we're already using Typesafe Config for our own configuration, even in our projects using Wisdom.

However, for components that require config to be active, we convert the Hocon file to a Configuration instance (using the ConfigurationAdmin spec). It makes things cleaner than having Configuration be a service, and is supported out-of-the-box by iPOJO & other OSGi component frameworks.

Is there any reason you're not doing this in Wisdom? I find injecting ApplicationConfiguration less elegant than the usual ConfigAdmin approach.

Also, we're using the latest Typesafe Config version while you currently embed 1.0.2. As it was now, there was no class-space issue because the Config dependency was only used by Akka and wasn't exposed to users of the Wisdom API. I suppose there's no reason Config should be exposed to API clients, but still it would be interesting to upgrade to the latest version.

Contributor

magnet commented Dec 27, 2014

Hey Clément,
Nice to see this work going, since we're already using Typesafe Config for our own configuration, even in our projects using Wisdom.

However, for components that require config to be active, we convert the Hocon file to a Configuration instance (using the ConfigurationAdmin spec). It makes things cleaner than having Configuration be a service, and is supported out-of-the-box by iPOJO & other OSGi component frameworks.

Is there any reason you're not doing this in Wisdom? I find injecting ApplicationConfiguration less elegant than the usual ConfigAdmin approach.

Also, we're using the latest Typesafe Config version while you currently embed 1.0.2. As it was now, there was no class-space issue because the Config dependency was only used by Akka and wasn't exposed to users of the Wisdom API. I suppose there's no reason Config should be exposed to API clients, but still it would be interesting to upgrade to the latest version.

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier Dec 27, 2014

Member

Hello Simon,

On 27 décembre 2014 at 12:28:35, Simon Chemouil (notifications@github.com) wrote:

Hey Clément,
Nice to see this work going, since we're already using Typesafe Config for our own configuration, even in our projects using Wisdom.

However, for components that require config to be active, we convert the Hocon file to a Configuration instance (using the ConfigurationAdmin spec). It makes things cleaner than having Configuration be a service, and is supported out-of-the-box by iPOJO & other OSGi component frameworks.

Is there any reason you're not doing this in Wisdom? I find injecting ApplicationConfiguration less elegant than the usual ConfigAdmin approach.

So, the idea is to avoid injecting the whole ApplicationConfiguration and to inject only the required data. This will be done in a way very close to yours. I’m exposing Configuration as services just for monitoring purpose when things are going to be modularized (with fallbacks), and for people willing to retrieve their Configuration object using @requires. But at the end, these configurations are going to be pushed in ConfigurationAdmin, so it can be used to instantiate and configure instances.

Why am I hiding the config admin ? Because of its complexity. Every time I pushed the config admin way, my developers were a bit lost. I think it’s coming from the poor type support the config admin has (primitive types, Strings, and vector of theses types). The whole ManagedService vs. ManagedServiceFactory story does not make things very clear either (especially it has been recently changed). So, I would like something simpler, where you don’t have to know all the details about the specification.

Also, we're using the latest Typesafe Config version while you currently embed 1.0.2. As it was now, there was no class-space issue because the Config dependency was only used by Akka and wasn't exposed to users of the Wisdom API. I suppose there's no reason Config should be exposed to API clients, but still it would be interesting to upgrade to the latest version.

Nope, it is using 1.2.1 which is the latest. Akka uses a rather old version, but we embed it inside the bundle to avoid the confusion.


Reply to this email directly or view it on GitHub.

Member

cescoffier commented Dec 27, 2014

Hello Simon,

On 27 décembre 2014 at 12:28:35, Simon Chemouil (notifications@github.com) wrote:

Hey Clément,
Nice to see this work going, since we're already using Typesafe Config for our own configuration, even in our projects using Wisdom.

However, for components that require config to be active, we convert the Hocon file to a Configuration instance (using the ConfigurationAdmin spec). It makes things cleaner than having Configuration be a service, and is supported out-of-the-box by iPOJO & other OSGi component frameworks.

Is there any reason you're not doing this in Wisdom? I find injecting ApplicationConfiguration less elegant than the usual ConfigAdmin approach.

So, the idea is to avoid injecting the whole ApplicationConfiguration and to inject only the required data. This will be done in a way very close to yours. I’m exposing Configuration as services just for monitoring purpose when things are going to be modularized (with fallbacks), and for people willing to retrieve their Configuration object using @requires. But at the end, these configurations are going to be pushed in ConfigurationAdmin, so it can be used to instantiate and configure instances.

Why am I hiding the config admin ? Because of its complexity. Every time I pushed the config admin way, my developers were a bit lost. I think it’s coming from the poor type support the config admin has (primitive types, Strings, and vector of theses types). The whole ManagedService vs. ManagedServiceFactory story does not make things very clear either (especially it has been recently changed). So, I would like something simpler, where you don’t have to know all the details about the specification.

Also, we're using the latest Typesafe Config version while you currently embed 1.0.2. As it was now, there was no class-space issue because the Config dependency was only used by Akka and wasn't exposed to users of the Wisdom API. I suppose there's no reason Config should be exposed to API clients, but still it would be interesting to upgrade to the latest version.

Nope, it is using 1.2.1 which is the latest. Akka uses a rather old version, but we embed it inside the bundle to avoid the confusion.


Reply to this email directly or view it on GitHub.

@magnet

This comment has been minimized.

Show comment
Hide comment
@magnet

magnet Dec 27, 2014

Contributor

OK, it makes sense! And it sounds good as long as the configuration ends up in ConfigAdmin so that it can be used along in other component frameworks like DS or advertised in other OSGi configuration tools (or in the command line).

Regarding the Config version, I looked a bit fast, thanks for clearing things up.

Contributor

magnet commented Dec 27, 2014

OK, it makes sense! And it sounds good as long as the configuration ends up in ConfigAdmin so that it can be used along in other component frameworks like DS or advertised in other OSGi configuration tools (or in the command line).

Regarding the Config version, I looked a bit fast, thanks for clearing things up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment