management of configuration

[nicolas de loof]

An aspect of configuration I want this JSR to address is management, from an Ops point of view.

Unzipping an *AR archive to edit some XML descriptor as JavaEE used to suggest is a non-sense from an Ops point of view. I don't think we will ever propose JavaEE apps to be distributed as RPM system packages, but we have to consider Ops practices and tooling with care.

Application delivery should be a self contained, single artifact, ready for production, and all deployment steps has to be scriptable (think about puppet/chef and other tools)

I'd like the configuration JSR to define a system level API so a configuration management tool can manage application config injecting configuration parameters and defining resources and bindings for application.

We could provide a command line tool for this purpose, but I have a preference for REST API, so it's easily usable from whatever languages (python, ruby, shell scripts). Docker has such an API to define application containers, even this is a lower level than what we're considering here, this is a good sample to follow. java-config could then offer a daemon to offer a REST endpoint and let configuration tools query/update the application configuration.

Note : a JavaEE container could also act as such a daemon and let Ops tool manage resources and application bindings directly.

create a new application :

POST applications/create

{

 // some optional JSON metadata, can be vendor specific

}

return application unique ID

create a managed resource, for sample a database connection pool

POST resources/create

{

    "type":"datasource",

    "url":"jdbc:....",

    // some more (can be vendor specific) parameters

}

return resource unique ID

set application parameters as key=value pairs

POST applications/id/parameters

{

      "foo":"bar"

}

could also easily support structured data if this makes sense.

bind a resource to an application 

POST applications/id/bindings

{

    "resouce":"id",

    "alias":"jdbc/db"

}

From application itself, can use this same API to retrieve application configuration during startup / deployment. On a standalone (SE) application, this can just be used by a javaagent to GET parameters and bindings and setup system properties and resources for starting application. 

On a JavaEE application, I advocate for System properties support, I think this is fully feasible with application isolation but arguably hack-ish (*). Anyway same mechanism to GET application configuration from daemon can be used for comparable purpose, injecting JNDI resources and offering a higher level, new API for direct consumption.

(*) many things on Java are hacks anyway. Looking at lambdas implementations using a private $ method demonstrates a clever hack, but still a hack. I don't think we should exclude such a solution just because it looks like a hack. Java is old now, and we have to ensure backward compatibility, so have to suffer this constraints. As a Jenkins committer I know well backward compatibility impact on API design and maintenance :P

[Anatole Tresch]

Hi Nocolas/all,

for me it will be an interesting question, how far to go here, because I think it may be a good idea to be careful not to constraînt vendors too much (from a JSR's risk aspect).

What I see would be for sure possible, is adding an API, that allows adding/defining configuration also programmatically. Of course there must then be an according mechanism added  to send out the "change events".

Interested parties (deployment engines, application server domain, applications etc.) then could react accordingly and start/instantiate, whatever needed.

One advantage would be that this JSR must not define, and also will not constraint, what would be possible to do with it. Vendors and also other EE JSRs can then define, how the want to benefit from this functionality. 

Also here I am looking forward for other opinions, but for keeping things minimal, I think, it may exceed the scope of an initial JSR, when defining a Rest API for all DevOps operations in all details...

Reading configuration using some JMX beans can also easily be proposed easily, nevertheless it might be questionable if this must be part of the spec or rather the RI.

As I said hacking System.getProperty, just for reusing an common singleton API, which is commonly used, but insufficient, I think is not the way to go. But I am open for discussion here, let's what other think.

If we want to support an already existing JDK API, I only see Preferences as a valuable alternative, though it has also its obvious weaknesses.

-Anatole

[Juven Xu]

This configuration manager, or configuration center is a must in large organization environment, for instance, we use zookeeper like tool to manage some dynamic configuration. The question is, do we want to include it into jsr? I think a more friendly approach is do define SPI for retrieving configuration, and let implementations to deal with their configuration manager. To me, the configuration manager is more like another tool (in my mind like Nexus for Maven).

​Juven 

—
Sent from Mailbox for iPad

--
You received this message because you are subscribed to the Google Groups "java-config" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-config...@googlegroups.com.
Visit this group at http://groups.google.com/group/java-config.
For more options, visit https://groups.google.com/groups/opt_out.

[nicolas de loof]

Agree, configuration manager has to vendor specific and at most can be standardized by a SPI

But this is not the point I'm talking about. I'm considering existing vs new API

We for sure can define a new ConfigurationService or whatever new API to access configuration a clean way

but 99% java framework rely on system properties, and/or classpath resources (xml/properties). Spring, I'm thinking on you here, but also Grails, PlayFramework, and many many others.

So my suggestion is that, if we want this JSR to get large adoption, we have to consider this de-facto standard. It's really few lines of code to inject system properties in a JVM. I agree doing this in JavaEE context WITH application isolation is hacky and some might not want to go this way. Anyway, considering the "embrace existing approach" point of view this is absolutely not a requirement. 

Nowadays, developer who want to setup a Spring webapp and use property placeholder just set system properties for the JVM running the application server, and as such either app is alone on appserver, either they prefix properties to create application namespaces. Both make sense and don't require extra efforts.

2013/10/26 Juven Xu <juve...@gmail.com>

[Juven Xu]

I think now I understand your point.

+1 for supporting injecting configuration from system properties and classpath resources.

On Saturday, October 26, 2013 11:03:16 PM UTC+8, nicolas de loof wrote:

Agree, configuration manager has to vendor specific and at most can be standardized by a SPI

But this is not the point I'm talking about. I'm considering existing vs new API

We for sure can define a new ConfigurationService or whatever new API to access configuration a clean way

but 99% java framework rely on system properties, and/or classpath resources (xml/properties). Spring, I'm thinking on you here, but also Grails, PlayFramework, and many many others.

So my suggestion is that, if we want this JSR to get large adoption, we have to consider this de-facto standard. It's really few lines of code to inject system properties in a JVM. I agree doing this in JavaEE context WITH application isolation is hacky and some might not want to go this way. Anyway, considering the "embrace existing approach" point of view this is absolutely not a requirement. 

Nowadays, developer who want to setup a Spring webapp and use property placeholder just set system properties for the JVM running the application server, and as such either app is alone on appserver, either they prefix properties to create application namespaces. Both make sense and don't require extra efforts.

2013/10/26 Juven Xu <juve...@gmail.com>

This configuration manager, or configuration center is a must in large organization environment, for instance, we use zookeeper like tool to manage some dynamic configuration. The question is, do we want to include it into jsr? I think a more friendly approach is do define SPI for retrieving configuration, and let implementations to deal with their configuration manager. To me, the configuration manager is more like another tool (in my mind like Nexus for Maven).

​Juven 

—
Sent from Mailbox for iPad

[Anatole Tresch]

• I am not sure, if we really agree here. Reading system properties, or configuration stored in some classpath, must be possible of course. This will be one of the key use cases.
  
• Adding configuration from additional resources, external or whereever accessible, must also be possible (hidden by some SPI).
• Hacking System.getProperty, so it behaves contextually for accessing configuration properties can be done by a reference implementation, BUT
• it can not be proposed (or even required) as part of a JSR. A JSR cannot change the backwards compatiblity of the Java platform itself, this would be useless (it would even create high risk on the whole JSR to fail on a ballot) and IMO also not necessary.

Nevertheless we can include that feature request, if not as part of the RI, also as external OSS extension library.

Cheers,

Anatole

[Juven Xu]

Sorry maybe I’m not following here, can you guys explain more on hacking System.getProperty ?

I did +1 for supporting config injection for system properties and classpath resources, but not for hacking System.getProperty

Thanks,

Juven

[nicolas de loof]

It's not about hacking System.proprerties, it's about a standard way to get configuration injected as key=value pairs as system properties.

It's just about a javaagent to retrieve JSR-configuration and use System.setProperty(name, value);

With such a mechanism, you don't need to wait for all frameworks to evolve and adopt configuration API.

I'm fine with a new API to access configuration from application code, but as I already said, my main interest on this JSR is configuration MANAGEMENT = how my Dev and Ops teams can manage application configuration so the same binary is deployed on various servers, but with distinct config injected. Preparing the future for next generation frameworks is nice, but not my daily job.

The configuration isolation and namespacing in JavaEE context is another stuff. I actually suggested a hack but I'm fine if this can't be standardized. Many ways to be addressed, including prepending "namespace." to all properties for a specific app. Most app server I've seen so far only host one application anyway.

2013/10/29 Juven Xu <juve...@gmail.com>

[Juven Xu]

Sorry maybe I’m not following here, can you guys explain more on hacking System.getProperty ?

I did +1 for supporting config injection for system properties and classpath resources, but not for hacking System.getProperty

Thanks,

Juven

[Henri Gomez]

As former Dev and today more minded Ops guy, I would agree.

A good approach would be to use some magic patterns so Ops could update contents if needed.

For example, JBoss way, aka ${myport:defaultvalue} is really good as there is a default mode (default value) to fallback.

Now, myvalue should be clearly identified in its namespace so Ops would only have to override value (whatever system used to inject conf) using this namespace :

org.apache.tomcat.http.myport = 18080

This will override myport values from configuration file under org.apache.tomcat.http name space.

About global configuration manager, there is plenty of solution around, like ASF Zookeper (http://zookeeper.apache.org/)

Did there is some notes/guidelines somewhere about what are java-config goals, as a base for configuration management in Java ?

Cheers