Hi Kristian Great to see more people being interested in our efforts and I also give my 5 Rappen here inline...
Best Anatole 2015-04-02 15:23 GMT+02:00 Kristian Rink <[email protected]>: > Hi Werner; > > and first off, thanks a bunch for your feedback. Even though this > obviously is not a feature packed with tamaya so far, glad to see it at > least has been on the agenda before already... :) > The requirement is common and IMO absolutely must have requirement. Nevertheless we wanted to start with a minimalistic release and gather more feedback to see, where people want us to define/extend the API. In all cases adding functionality with a module is always an option, too. Said that I think there is even an environment module already in the experimental module tree, or we can easily provide one. Nevertheless there are a few questions, we might discuss here: - How we want to model the Stage: - as an interface? - As a specialized configuration entry? - A mixture: configuration entry, which can be accessed as Stage in a type safe manner? Given that the minimal model of a stage would be a simple String (name), accessible from the current configuration with a predefined key. But how is configuration now reacting to that? Basically you have multiple options: a) you can use the name to identify the locations to be searched for stage specific config. This could be locations in classpath, on the filesystem or whatever source useful. b) you can use the name to filter keys that are read, e.g. you might have a configuration format that contains stage specific sections (possible with multiple different formats). A specialized *StagePropertySource *could be added with higher ordinal that implements that logic. Basically a 5 liner, especially when reusing the functionality provided by some other modules, e.g. for resource locations and format abstractions. How your filter mechanism is implemented may also depends on your taste, or your already existing environment). You can use the "stage" as - prefix - section identifier - meta data filter Given that defining and adding a concrete mechanism for stage support will quite probably fail because people want to have different ways how a stage is handled, how stage specific configuration is identified and selected. What I see as a common minimal aspects is the definition/modeling of the "stage" as outlined above. Nevertheless Tamay may also provide some more concrete stage support as a module or as an example, but it should always be optional, so someone that does not like our stage handling, can easily handle it differently. The SPI in place, especially with the *PropertySource *and *PropertyFilter *mechanism is so powerful that all mentioned scenarios above can be easily implemented. BTW: in Credit Suisse we have overrides in place by default for stage, app level (ear, app), defaults/non-defaults, tier, server, resource type (system properties > files > cp resources). All this can be done with Tamaya as it is already now ;) So, to pour in some of our ideas on that... Generally, there are three different issues we try to solve, configuration-wise: > > - "continuous delivery" / deployment to various systems (testbed, staging, > production) without the need to manually change anything in any of the > artifacts deployed, including launcher scripts and all that; currently our > applications (Linux-based) are started using shell scripts, and this is > what made us think about something like the RoR environments (and possibly > an approach to set a system environment variable which a Java application > starter should evaluate), but I am not sure whether this is the best idea; > With a system property you can set a configuration parameter OOTB. It is directly added to the default configuration. Dynamic replacements can be added by using the resolver module, you also can add your own resolvers easily (reading from an URL is supported OOTB). Remote configuration support is definitively also on my list and if I find more time (hopefully when the money JSR is final), I will write a remote configuration example/module to support this kind of requirement. In the core part there is already a functionality to "freeze" a configuration, meaning render its current state into a static and serializable form. There is also a JSON module that is able to translate any configuration into a JSON tree. So all main building blocks are there. - having a sane, clear way of generally managing application > configurations, which becomes painful especially the very moment an > application configuration changes by introducing new keys or options that > are required to be correctly set on all systems; this is where so far we > thought about either deploying all the configuration files in .properties > or .json structures all along with the application (and having > *_production.json, *_testing.json, ... for the different environments, see > above, available on the system), or about having a central repository (on a > file server or in an Apache CouchDB installation) where each application > points to find the configuration to use on its current host; > As mentioned the problem is that different people/companies will want to handle things differently. I don't see much chance for a standard that contains all these aspects, but only for the building mechanism and access API. Nevertheless it might be useful to provide some default "configuration meta-models" as extension modules. They help us to bullet prove our concepts and similarly provide directly usable models: if you are satisfied with a meta-model, add it as dep, and start using it. If not, check out the code and adapt it to your needs ;) > > - maintaining a structure that includes a notion of "global" and > "application-specific" configurations, knowing that there are things that > are likely to be the same on many or all applications in one environment > (like JDBC URLs for data sources, message bus URLs, REST endpoints for > external systems, SSO integration, ...); so far we had no real other idea > for that but to provide two different sources (files, documents, ...) for > configuration entries - "global" and "application_XX" ... . > Summarizing first thing to do: define EXACTLY how your configuration tree is built up: - which resources are read - which is the/are the configuration format(s) allowed - multiple can be possible. - which config may override entries from other config. - what kind of dynamics you want: value resolution, complete parts of a config subcases: constraint on a defined keyset, or able to add arbitrary keys Implement the given hierarchy identified, typically with a set of PropertySourceProvider that produce PropertySources (with different ordinals). You can use PropertyFilter for changing the configuration tree after it has been evaluated if needed on top. For more contextual behaviour you may reimplement register a more powerful version of ConfigurationProvider. This is also planned in a later release (e.g. supporting Java EE, OSGI, or other multiclassloader environments). That's, in a nutshell, just a brain dump of our configuration issue so far. > Consequently, we're looking for something that does most of this and does > most of this out of the box. Our current idea, indeed, was to create > something like a local "commons-configuration" implementation building on > top of Apache CouchDB (as a store) and some REST/JSON library and provide a > facade to retrieve global and application specific configurations for > various applications based upon an application name and an environment > descriptor. But then again, I am pretty sure we're not the only ones > dealing with such problems... ;) > Definitivly not ;) you can even mix resources, reading parts out of your classpath, from your local deployment or from the database, or even from a distributed data grid. All is possible. Since your ideas sounds very reasonable I would like to offer my help to write an example as outlined by you. Doing this will help to see, where we need more abstractions and also would should the power of Tamaya. WDYT? Best Anatole > All the best, > Kristian > -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Glärnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
