You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tamaya.apache.org by an...@apache.org on 2015/01/12 23:33:01 UTC
[6/6] incubator-tamaya git commit: TAMAYA-43: Tried fix for
resolution on Linux box.
TAMAYA-43: Tried fix for resolution on Linux box.
Project: http://git-wip-us.apache.org/repos/asf/incubator-tamaya/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-tamaya/commit/d4037e72
Tree: http://git-wip-us.apache.org/repos/asf/incubator-tamaya/tree/d4037e72
Diff: http://git-wip-us.apache.org/repos/asf/incubator-tamaya/diff/d4037e72
Branch: refs/heads/master
Commit: d4037e720e6f4f21b1b25e683642ef7711f74c7f
Parents: 085c3f8
Author: anatole <an...@apache.org>
Authored: Mon Jan 12 23:32:17 2015 +0100
Committer: anatole <an...@apache.org>
Committed: Mon Jan 12 23:32:17 2015 +0100
----------------------------------------------------------------------
docs/src/main/asciidoc/design/0_UseCases.adoc | 284 -------------------
.../main/asciidoc/design/1_Requirements.adoc | 249 ----------------
docs/src/main/asciidoc/design/Design.adoc | 117 --------
3 files changed, 650 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/d4037e72/docs/src/main/asciidoc/design/0_UseCases.adoc
----------------------------------------------------------------------
diff --git a/docs/src/main/asciidoc/design/0_UseCases.adoc b/docs/src/main/asciidoc/design/0_UseCases.adoc
deleted file mode 100644
index 9414c98..0000000
--- a/docs/src/main/asciidoc/design/0_UseCases.adoc
+++ /dev/null
@@ -1,284 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements. See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership. The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License. You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied. See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
-<<<
-[[UseCases]]
-== Use Cases
-
-This section describes some, but not all, of the use cases that should be covered by Tamaya.
-
-
-[[UCSimpleAccess]]
-=== Simple Property Access (UC 1)
-
-Users just want to create a configuration (or configuration template) ad hoc, from given configuration files. The
-files could be locally in the file system, on the classpath or remotely accessible by some URLs.
-
-Tamaya should provide a simple Java API for accessing key/value based configuration. Hereby users want to access
-properties as
-
-* Strings
-* Primitive types
-* Wrapper types
-* All other types
-
-
-[[UCConfigInjection]]
-=== Automatic Configuration (Configuration Injection, UC2)
-
-Tamaya must provide a feature for automatic configuration, where properties of a class or methods can be annotated.
-
-* Hereby the lifecycle of the instances configured should not be managed by Tamaya. Also users want to define default
-values to be used in case no configured value is present.
-* Users want to have callbacks so they can listen on configuration changes.
-* Users want to evaluate multiple keys, e.g. current keys, and as a backup, deprecated keys
-from former application releases.
-* Users want to use dynamic placeholders in their value expressions.
-* Users want to have full control about value evaluation and type conversion, if necessary.
-
-To illustrate these points above imagine the following POJO:
-
-[source, java]
-.Configured POJO Example
-----------------------------------------------------
-public class MyPojo {
- @ConfigProperty("myCurrency")
- @DefaultValue("CHF") // use as default
- @WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value only once (no reinjection)
- private String currency;
-
- @ConfigProperty("myCurrencyRate")
- private Long currencyRate;
-
- @ConfigProperty // evaluates to key=<fieldName>="fullRate"
- @ConfigProperty("fallback.property")
- @WithConfig("default")
- @WithConfig("moduleConfig");
- private BigDecimal fullRate;
-
- // Configuration method
- void setStartup(@ConfigProperty boolean startup, @ConfigProperty("componentName") @WithConfig("module1") @DefaultValue("N/A") String compName){
- ...
- }
-
- // Configuration method
- @ConfigProperty("componentName")
- @WithConfig("module1")
- @DefaultValue("N/A")
- private void setComponentName(String compName){
- ...
- }
-
- // Configuration listener method, defining which properties to listen for
- @ConfigChanges
- @ConfigProperty("componentName")
- private void setComponentName(ConfigChange change){
- ...
- }
-
-}
-----------------------------------------------------
-
-The instance then can be passed for being configured:
-
-[source, java]
-.Configuring a POJO
-----------------------------------------------------
-MyPojo instance = new MyPojo();
-Configuration.configure(instance);
-----------------------------------------------------
-
-This will configure all values according to the load policies (by default +LoadPolicy.INITIAL+). Depending on the
-listeners present and the properties injected Tamaya will keep weak references to the bean and the current environment,
-so it can be determined, when configuration changes must be published into the bean.
-
-[[UCTemplates]]
-=== Configuration Templates (UC3)
-
-For type safe configuration clients should be able to define an interface and let it implement by the
-configuration system based on configuration available. Following an example template is shown, which illustrates
-annotating an interface with the same annotations as for configured classes:
-
-[source, java]
-.Type Safe Configuration Template Example
-----------------------------------------------------
-public interface MyConfig {
-
- @ConfiguredProperty("myCurrency")
- @DefaultValue("CHF")
- String getCurrency();
-
- @ConfiguredProperty("myCurrencyRate")
- Long getCurrencyRate();
-
- @ConfigChange
- default configChanged(ConfigChange event){
- ...
- }
-
-}
-----------------------------------------------------
-
-The configuration system will then provide the interface as follows:
-
-[source, java]
-.Accessing a type safe Configuration Template
-----------------------------------------------------
-MyConfig config = Configuration.current(MyConfig.class);
-----------------------------------------------------
-
-Finally a +Configuration+ itself can be accessed as template as well, which
-provides full access to all features:
-
-[source, java]
-.Accessing a Configuration
-----------------------------------------------------
-Configuration config = Configuration.current(Configuration.class);
-----------------------------------------------------
-
-
-[[UCSimpleConfiguration]]
-=== Simple Property Based Configuration (UC4)
-
-In this most simple usage scenario an application is configured by some property files contained in the
-Java archive. Tamaya should provide a reasonable default meta-model, if no meta-model is currently loaded.
-
-Additionally users want (optionally) to override settings by applying system properties or other command line
-arguments.
-
-
-[[UCAdvancedPropertyBasedConfiguration]]
-=== Advanced Property Based Configuration (UC5)
-
-Enhancing the previous scenario, we might as well consider the current environment. Saying that our overriding mechanisms
-must be improved, since people do not want all properties to be mutable.
-Dynamic placeholders should be supported for values.
-It is also possible to add environment values to a configuration.
-
-[[UCModularizedConfiguration]]
-=== Modularized Configuration (UC6)
-
-When systems grow they must be modularized to keep control. Whereas that sounds not really fancy, it leads to additional
-aspects to be considered by a configuration system.
-
-* Different code modules want to have their "own" configuration.
-* Some modules require a certain subset of keys to be read at once into a Map.
-* Products contain multiple modules, which per product are configured separately.
-
-
-[[UCTypeSupport]]
-=== Extended Type Support (UC7)
-
-Application configuration must also support non String types such as primitives, wrapper types, math types
-and date/time values. Basically each type that can be created from a String in more standardized way should
-supported. This should be even possible for types not known at build time of possible. Type conversion hereby
-should be flexible and extensible.
-
-[[UCDynamicProvisioning]]
-=== Dynamic Provisioning (UC8)
-
-In Cloud Computing, especially the PaaS and SaaS areas a typical use case would be that an application (or server)
-is deployed, configured and started dynamically. Typically things are controlled by some "active controller components",
-which are capable of
-* creating new nodes (using IaaS services)
-* deploying and starting the required runtime platform , e.g. as part of a PaaS solution.
-* deploying and starting the application modules.
-
-All these steps require some kind of configuration. As of today required files are often created on the target node
-before the systems are started, using proprietary formats and mechanism. Similarly accessing the configuration in place
-may require examining the file system or using again proprietary management functions. Of course, a configuration
-solution should not try to solve that, but it can provide a significant bunch of functionality useful in such scenarios:
-
-* provide remote capabilities for configuration
-* allow configuration to be updated remotely.
-* allow client code to listen for configuration changes and react as needed.
-
-
-[[UCJavaEE]]
-=== Java EE (UC9)
-
-Considering Java EE different aspects should be considered:
-
-* Java EE is a complex multi-layered architecture with different levels of runtime contexts:
-** application server boot level (system classloader),
-** (optional) deployment/undeployment of ears (ear classloader),
-** (optional) deployment/undeployment of web applications (war classloader),
-** different runtime setups, e.g. EJB calls, MDB execution, Servlet Requests, scheduled and timed executions.
-* Configuring administrative resources (e.g. datasources, users, security etc) is typically vendor specific.
-* The environment is inherently multi-threaded.
-
-[[UCMultiTenancy]] (UC10)
-=== Scenario MultiTenancy
-In multi tenancy setups a hierarchical/graph model of contexts for configurations is required. For example there might
-be some kind of layering as follows:
-
-* Layer 0: Low level system configuration
-* Layer 1: Domain configuration
-* Layer 2: Default App configuration
-* Layer 3: Tenant specific configuration
-* Layer 4: User specific configuration
-
-
-[[UCJavaAPI]] (UC11)
-=== Accessing Configuration
-
-So far we described much how configuration must be organized and managed, but we got not concrete, how it is accessed.
-Basically there are two basic scenarios to be distinguished, which mainly depend on the way how the lifecycle of a component
-to be configured is managed:
-
-* If the lifecycle is managed manually by the developer, the configuration system
-** can inject configuration values, when explicitly called to to so
-** can provide an accessor for configuration.
-* If the lifecycle is managed by some container such as a DI container, the configuration
- system should leverage the functionality of the container, where possible.
-
-
-[[UCTesting]]
-=== Testing (UC12)
-When testing a Java solution, it must be possible to easily control the configuration provided, so isolated
-component tests can be written effectively. Also it should be possible to control/isolate the configuration level for
-each test case.
-
--> isolation of configuration services is required
-
--> API for controlling the configuration provided, required for according implementations in the testing frameworks.
-
-[[UCStaging]]
-=== Staging (UC13)
-Different companies go through different staging levels during the development of software components. Currently only
-rarely the EE frameworks support staging aspects, nevertheless no broader, well modelled staging concept is defined.
-Different companies also have different staging or sub-staging levels in place, which also must be reflected.
-Especially with sub-stages inheritance of stage related configuration is common sense and should be supported.
-
--> Main stages available and to be supported must be defined.
-
--> Enable additional stages to be added, so also custom stages can be supported.
-
-
-[[UCCotsIntegration]]
-=== Custom of the Shelf (COTS) Integration (UC14)
-When buying software from an external software company it is often very cumbersome to integrate, adapt and customize
-third party software to the internal operational requirements. Especially, when software is delivered as ear modules
-portability is often very difficult and time consuming. Configuration should enable COTS providers to define a
-customization contract, which also can be part of the COTS software interface and integration specifications. This
-would allow operations to better control and configure third party solutions as possible, whereas in the evaluation
-phase the integration and configuration options can explicitly be defined.
-
--> It must be possible to document configuration aspects supported.
-
--> Configuration must be adaptable from external sources (the operations which must operate the COTS solution).
-
http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/d4037e72/docs/src/main/asciidoc/design/1_Requirements.adoc
----------------------------------------------------------------------
diff --git a/docs/src/main/asciidoc/design/1_Requirements.adoc b/docs/src/main/asciidoc/design/1_Requirements.adoc
deleted file mode 100644
index 00d32a3..0000000
--- a/docs/src/main/asciidoc/design/1_Requirements.adoc
+++ /dev/null
@@ -1,249 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one
-// or more contributor license agreements. See the NOTICE file
-// distributed with this work for additional information
-// regarding copyright ownership. The ASF licenses this file
-// to you under the Apache License, Version 2.0 (the
-// "License"); you may not use this file except in compliance
-// with the License. You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing,
-// software distributed under the License is distributed on an
-// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-// KIND, either express or implied. See the License for the
-// specific language governing permissions and limitations
-// under the License.
-
-<<<
-[[Requirements]]
-== Requirements
-=== Core Configuration Requirements
-==== General
-
-Tamaya must provide a Java SE API for accessing key/value based configuration. Hereby
-
-* +Configuration+ is modelled by an interface
-* +Configuration+ is organized as key/value pairs, using a subset of functionality present on +Map<String,String>+ as
- follows:
- ** access a value by key (+get+)
- ** check if a value is present (+containsKey+)
- ** get a set of all defined keys (+keySet+)
- ** a configuration must be convertible to a +Map+, by calling +toMap()+
- ** a configuration must provide access to its meta information.
-* +Configuration+ value access methods must never return null.
-* The API must support undefined values.
-* The API must support passing default values, to be returned if a value is undefined.
-* The API must allow to throw exceptions, when a value is undefined. Customized exceptions hereby should be supported.
-* Properties can be stored in the classpath, on a file or accessible by URL.
-* Properties can be stored minimally in properties, xml-properties or ini-format.
-
-
-==== Minimalistic Property Source
-
-For enabling easy integration of custom built configuration sources a minimalistic API/SPI must be defined, that
-
-* is modelled by an interface
-* is a minimal subset of +Configuration+ necessary to implement a configuration.
-* must be convertible to a "Configuration+.
-
-==== Extension Points
-
-For supporting more complex scenarios, +Configuration+
-
-* must implement the composite pattern, meaning new +Configuration+ instances can be created by combining existing
- configurations.
-* must be adaptable, by creating a new configuration by applying a +UnaryOperator<COnfiguration>+ to it.
-* must be queryable, by passing a +ConfigQuery+ to an +Configuration+ instance.
-
-
-==== Type Safety
-
-Besides Strings +Configuration+ should also support the following types:
-
-* Primitive types
-* Wrapper types
-* All other types (by using a +PropertyAdapter+
-
-Hereby type conversion should be done as follows:
-
-# Check if for the given target type an explicit adapter is registered, if so, use the registered adapter.
-#If no adapter is present, check if the target type T has static methods called +T of(String), T getInstance(String), T valueOf(String), T from(String)+. If so
-use this method to create the non value of T.
-# Check if the target type has a constructor T(String). If so, try to instantiate an instance using the constructor.
-# Give up, throw a IllegalArgument exception.
-
-=== Configuration Fomats
-
-By default Tamaya support the following configuration formats:
-
-* .properties
-* .xml properties
-* .ini files
-
-It must be possible to add additional formats by registering them with the current +ServiceContext+.
-
-=== Mutability
-
-* Configurations can be mutable, mutability can be accessed as a property.
-* Configuration can be changed by collecting the changes into a +ConfigCHangeSet+ and apply this set to the
- given +Configuration+ instance.
-* Besides the points above, +Configuration+ is immutable.
-
-=== Serializability and Immutability of Configuration
-
-* Configuration is modelled as a service. Therefore serialization may not work. This can be mitigated by adding
- a freeze feature, where the know key/value pairs are extracted into an immutable and serializable form.
-
-=== Configuration Combination Requirements
-
-At least the following composition policies must be supported:
-
-* override: subsequent entries override existing ones.
-* aggregate-exception: key/values were added, in case of conflicts a +ConfigException+ must be thrown.
-* aggregate-ignore-duplicates: similar to union, whereas duplicates are ignored (leaving the initial value loaded).
-* aggregate-combine: conflicting entries were resolved by adding them both to the target configuration by
- redefining partial keys.
-* custom: any function determining the key/values to be kept must be possible
-
-When combining configuration it must also be possible to override (file/classpath) configuration by
-
-* system properties.
-* command line arguments.
-
-
-=== Configuration Injection
-
-As metnioned configuration can be injected by passing a unconfigured instance of an annotated class to the
-+Configuration.configure+ static method:
-
-[source, java]
-.Configuring a POJO
-----------------------------------------------------
-MyPojo instance = new MyPojo();
-Configuration.configure(instance);
-----------------------------------------------------
-
-Hereby
-* It must be possible to define default values to be used, if no valid value is present.
-* It must be possible to define dynamic expressions, at least for default values.
-* The values configured can be reinjected, if the underlying configuration changes. This should also be the case
- for final classes, such as Strings.
-* Reinjection should be controllable by an loading policy.
-* It must be possible to evaluate multiple keys, e.g. current keys, and as a backup deprecated keys
- from former application releases.
-* It must be possible to evaluate multiple configurations.
-* The type conversion of the properties injected must be configurable, by defining a +PropertyAdapter+.
-* The value evaluated for a property (before type conversion) must be adaptable as well.
-* It must be possible to observe configuration changes.
-
-The following annotations must be present at least:
-
-* *@ConfiguredProperty* defining the key of the property to be evaluated. It takes an optional value, defining the
- property name. It must be possible to add multiple annotations of this kind to define an order of evaluation
- of possible keys.
-* *@DefaultValue* (optional) defines a default String value, to be used, when no other key is present.
-* *@WithConfig* (optional) defines the name of the configuration to be used. Similar to +@ConfiguredProperty+ multiple
- configuration can be defined for lookup.
-* *@WithConfigOperator* allows to adapt the String value evaluated, *before* it is passed as input to injection or
- type conversion.
-* *@WithPropertyAdapter* allows to adapt the conversion to the required target type, hereby overriding any default
- conversion in place.
-* *@WithLoadPolicy* allows to define the policy for (re)injection of configured values.
-* *@ObservesConfigChange* allows to annotate methods that should be called on configuration changes.
-* *@DefaultAreas" allows to define a key prefix key to be used for the configured key, if no absolute key
- is defined.
-
-=== Configuration Templates
-
-For type safe configuration clients should be able to define an interface and let it implement by the
-configuration system based on +Configuration+ available:
-
-* Clients define an interface and annotate it as required (similar to above)
-* The interface methods must not take any arguments
-* The configuration system can be called to return such an interface implementation.
-* The configuration system returns a proxy hereby providing type-safe access the values required.
-* Similar to configured types also templates support multiple values and custom adapters.
-* It is possible to listen on configuration changes for templates, so users of the templates
- may react on configuration changes.
-
-The following snippet illustrates the requirements:
-
-[source, java]
-.Type Safe Configuration Template Example
-----------------------------------------------------
-public interface MyConfig {
-
- @ConfiguredProperty("myCurrency")
- @DefaultValue("CHF")
- String getCurrency();
-
- @ConfiguredProperty("myCurrencyRate")
- Long getCurrencyRate();
-
- @ConfigChange
- default configChanged(ConfigChange event){
- ...
- }
-
-}
-----------------------------------------------------
-
-Templates can be accessed by calling the +Configuration.current(Class)+ method:
-
-[source, java]
-.Accessing a type safe Configuration Template
-----------------------------------------------------
-MyConfig config = Configuration.current(MyConfig.class);
-----------------------------------------------------
-
-[[RequirementsServer]]
-=== Server Configuration Requirements
-
-* Ensure Configuration can be transferred over the network easily.
-* Beside serializability text based formats for serialization in +XML+ and +JSON+ must be defined.
-* A management API must be defined, which allows to inspect the configuration in place, e.g. using
- JMX or REST services.
-
-[[RequirementsJavaEE]]
-
-Java EE leads to the following requirements:
-
-* Configuration must be contextual, depending on the current runtime context (e.g. boot level, ear, war, ...).
-* Hereby contextual aspects can even exceed the levels described above, e.g. for SaaS scenarios.
-* Resources can be unloaded, e.g. wars, ears can be restarted.
-* The different contextual levels can also be used for overriding, e.g. application specific configuration
-may override ear or system configuration.
-* Configuration may be read from different sources (different classloaders, files, databases, remote locations).
-* Configuration may be read in different formats (deployment descriptors, +ServiceLoader+ configuration, alt-DD feature, ...)
-* JSF also knows the concept of stages.
-* Many SPI's of Java EE require the implementation of some well defined Java interface, so it would be useful if the
- configuration solution supports easy implementation of such instances.
-* In general it would be useful to model the +Environment+ explicitly.
-* Configuration used as preferences is writable as well. This requires mutability to be modelled in way, without the
- need of synchronization.
-* JNDI can be used for configuration as well.
-
-[[RequirementsMultitenancy]]
-
-Configurations made in the tenant or user layer override the default app configuration etc., so
-
-* It must be possible to structure Configuration in layers that can override/extend each other.
-* The current environment must be capable of mapping tenant, user and other aspects, so a corresponding configuration
- (or layer) can be derived.
-
-[[RequirementsExtensions]]
-=== Extensions Requirements
-
-It must be possible to easily add additional functionality by implementing external functional interfaces operating
-on +Configuration+.
-
-* +UnaryOperator<Configuration>+ for converting into other version of +Configuration+.
-* +ConfigQuery<T>+ extending +Function<T, Configuration>+.
-
-[[RequirementsNonFunctional]]
-=== Non Functional Requirements
-THe following non-functional requirements must be met:
-
-* tbd
-
http://git-wip-us.apache.org/repos/asf/incubator-tamaya/blob/d4037e72/docs/src/main/asciidoc/design/Design.adoc
----------------------------------------------------------------------
diff --git a/docs/src/main/asciidoc/design/Design.adoc b/docs/src/main/asciidoc/design/Design.adoc
deleted file mode 100644
index 4865ca1..0000000
--- a/docs/src/main/asciidoc/design/Design.adoc
+++ /dev/null
@@ -1,117 +0,0 @@
-Apache Tamaya -- Design Documentation
-=====================================
-:name: Tamaya
-:rootpackage: org.apache.tamaya
-:title: Apache Tamaya
-:revnumber: 0.1-SNAPSHOT
-:revremark: Incubator
-:revdate: November 2014
-:longversion: {revnumber} ({revremark}) {revdate}
-:authorinitials: ATR
-:author: Anatole Tresch, Anatole Tresch
-:email: <at...@gmail.com>
-:source-highlighter: coderay
-:website: http://tamaya.incubator.apache.org/
-:iconsdir: {imagesdir}/icons
-:toc:
-:toc-placement: manual
-:icons:
-:encoding: UTF-8
-:numbered:
-
-'''
-
-<<<
-
--> add image : : https://raw.githubusercontent.com/JavaConfig/config-api/master/src/main/asciidoc/images/javaconfig.jpg[]
-
-toc::[]
-
-<<<
-:numbered!:
------------------------------------------------------------
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
------------------------------------------------------------
-
-:numbered:
-
-<<<
-
-== Introduction
-This document describes the {name} API for Configuration. The technical objective is to provide a
-unified configuration model in Java, targeting Java ME, SE as well as the EE platform.
-The API will provide support for key/value based application configuration. It will provide
-as well higher level APIs that are based on the low level ke</value pairs. Finally it will
-provide extension points for adding additional features and additional modules for extension
-or adaption.
-
-=== Working Group
-This work is being conducted as part of a community lead joint effort under the Apache Software Foundation. This
-specification is the result of the collaborative work of the members of the {name} Users Group and the community at
-large. Currently the project is lead by Anatole Tresch (atsticks at gmail.dot com).
-
-=== Goals
-Configuration is a key feature in all kind of programming languages. Basically configuration is the parametrization of
-well defined aspects of a software product without having to recompile/rebuild the code.
-
-==== Targets
-{name} targets to support all general configuration aspects, e.g.
-
-* spplication configuration
-** plugins
-** modules
-** components
-* Configuration of Java EE related aspects for Java enterprise application portability and dynamic provisioning, such as
-** 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, or by providing
- accessors to evaluate current configuration vlues. This can be used explicitly or transparently by client code.
-
-Additionally the solution should support
-
-* 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 of collections
-
-
-=== Required Java version
-The API is based on Java SE 8.0 language features.
-
-=== How this document is organized
-There are five main section in this document:
-
-* Use cases.
-* Requirements.
-* Specification.
-* Implementation Recommendations.
-* An appendix.
-
-<<<
-include::src/main/asciidoc/design/0_UseCases.adoc[]
-
-<<<
-include::src/main/asciidoc/design/1_Requirements.adoc[]
-
-<<<
-include::src/main/asciidoc/design/2_CoreConcepts.adoc[]
-
-:numbered!:
-== APPENDIX
-