Apache Tamaya — Documentation

a simple key/value based configuration model.

a uniform API for accessing configuration, regardless if you are running in a Java SE, Java EE or OSGI environment. This API is capable of hiding all the complexities in configuration management, your developers only need to know, where and in which format configuration can be added to the system.

the uniform API has another big advantage: it allows your code to be written against one single configuration API. You can use Tamaya's extension for validating and documententing your modules, applications or systems. And you provide your customers a simple to use SPI for integrating your solution with the customer's environment.

A ConfigurationBuilder allowing you to create a configuration completely manually and managing the configuration lifecycle on your own.

the API is implemented by a minimalistic core implementation, which in the future might also be targeting Java ME environments.

a powerful SPI that allows you to extend/adapt Tamaya with all kind of additional functionality commonly used in many use cases. Tanaya itself provides quite a few of the so called extensions, so you decide which features you want to use.

a bunch of modules that can be added to your classpath thus adding different functionality to your system as needed.

Tamaya comes as a modular framework, where you have to decide, which features make sense for you. So you have to do a selection, which modules make sense. The core implementation provides a fully usable solution, but many of you will want to add some extensions to benefit from additional functionality.

Though Tamaya comes with a very minimalistic configuration scheme out-of-the-box, it does by default typically not cover complex enterprise requirements. Also here Tamaya offers hooks and examples showing how you can easily replace your current configuration logic with Tamaya. So you must know how you want to organize configuration in your enterprise context, such as supported file locations, formats, overriding and filter rules, governance etc.

In an enterprise context you can easily implement a configuration architecture for your whole company and deploy the logic as an extension module. All application development teams in your company can then depend on this module (and the basic Tamaya core implementation). As a result all applications/modules in your company follow the same configuration policy, which makes it much more simpler to move people between your teams and projects. Similarly additional tooling functionality can help you to manage configuration on application as well as on enterprise level, e.g. providing command line or REST support to access the supported configuration entries, types and values, configuration validation and more.

If you are writing an application, application component or library you can support configuration using Tamaya by adding it as a dependency. Tamaya is rather small but if done all users/customers can use Tamaya to connect your solution with their current enterprise configuration infrastructure transparently. As an example you can use Tamaya to read your default configuration files, but since Tamaya is so easily extendable, customers can deploy an additional jar, which then allows them to add their own configuration mechanisms such as databases, datagrids or REST services.

Finally Tamaya also provides quite a few of very useful extensions that you may find useful. Also here you can shipd these extensions as part of your product, or you can let your users/customers optionally provide an SPI, where they can plug in whatever additional configuration or monitoring logic they want to be added.

application configuration

Container configuration, e.g. of Java EE enabling portability and dynamic provisioning

Configuration of CDI (interceptors, decorators and alternatives)

Configuration of Bean Validation, JSF, web applications etc.

Configuration of instances within Java SE, e.g. by passing instances to a method that injects configured values, and by providing accessors to evaluate current configuration values. This can be used explicitly or transparently by client code.

multiple configuration locations, including remote locations

multiple configuration formats, including custom formats

multiple configuration loading mechanisms, including custom mechanisms. By default reading the classpath, files und URIs are supported by default.

type conversion

configuration filtering and property adapters

configuration of collections

The API is a complete configuration API, that provides the minimum of functionality needed. It is modelled in a extensible way and only requires a few kb. It is not dependent on Java EE so it matches similarly all kind of microservice or OSGI architectural styles. The main features supported by the API.html are:

The Core implements the API. Basically with the core part (and the API) you are ready to go, but you may want to add additional extensions that provide more features that are very useful.

Extensions are additional libraries that you can add to your project setup. Most important features are:

Finally the documentation module provides comprehensive documentation on all features provided.

If you want to have a deeper look at the API/SPI, we recommend the API documentation.

If you want to have an overview about the available modules, continue here.

If you want to look to the numerous examples, continue here.

If you are interested in the software design in place, continue here.

General API Documentation and API Javadoc for Java7 / API Javadoc for Java8

General Core Documentation and Core Javadoc for Java7 / Core Javadoc for Java8