incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Incubator Wiki] Update of "TamayaProposal" by Anatole Tresch
Date Sat, 08 Nov 2014 09:40:26 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The "TamayaProposal" page has been changed by Anatole Tresch:
https://wiki.apache.org/incubator/TamayaProposal?action=diff&rev1=11&rev2=12

Comment:
Streamlined proposal.

  
  
  == Proposal ==
- Tamaya is a highly flexible configuration solution based on an modular, extensible and
+ Tamaya is a highly flexible configuration API based on an modular, extensible and
- injectable key/value based design. The basic building block hereby are
+ injectable key/value based design. The basic building blocks hereby are:
+ 
- ''property providers'' implementing a small and easily implementable subset of a
+  * ''property providers'' implementing a small and easily implementable subset of a `Map<String,String>`.

- ´Map<String,String>´. This simplicity comes with a long list of decent advantages
- such as
+  * support for configuration injection
+  * a type-safe configuration template mechanism
+  * serializable and remote configuration support
+  * a JMX/Rest based management console
+  * Configuration will follow the GoF composite pattern and support several combination strategies.
+  * An extendible and adaptable environment model, so configuration can be provided dependent
of the environment currently active.
+  * extension points and a powerful SPI to seamlessly add additional logic to the API, such
as secured views, multi-valued validation schemes, en-/decryption etc.
+  * Configuration (and property providers) are designed and implemented as indirectly mutable
types, providing thread-safe and performant to configuration.
+  * Configuration changes can be observed by listening on `ConfigChange` events.
  
+ The API's focus is on simplicity and ease of use. Developers should only have to know a
minimal set of artifacts to work with the solution.
+ The API is built on latest Java 8 features and therefore fit perfectly with the functional
features of Java 8.
-  * capability of easily being combined with each other using different combination policies
into new composite providers, e.g.
-   * '''add-ignore:''' Add all entries to an existing provider, but ignore all entries already
existing in the base provider.
-   * '''add-override''' Add all entries to an existing provider, but override all entries
already existing in the base provider with the values from the added provider.
-   * '''add_distinct:''' Add all entries to an existing provider, but require that all keys
are distinct, throwing a `ConfigException` if they are not.
-   * '''intersection:''' create a provider with key/values identical in both participating
providers.
-   * '''union:''' Adding key/values from multiple providers, resolving conflicts by some
policy (renaming, prefixing, ...).
-   * '''filtering:''' Interpreting a second providers as a multi-valued filter matrix, filtering
the based provider.
-   * ...
-  * capability of easily serialize data and therefore also support configuration management
and remote configuration distribution solution.
-  * no intersection with existing standard, especially CDI in the Java EE context.
-  * Simplicity in use and implementation
-  * Unified representation of all kind of possible configuration data (low level, higher
level functions are provided by the `Configuration` abstraction.
-  * Ease of reuse of existing Java platform provided default properties formats (properties,
xml-properties).
  
+ Additionally Apache Tamaya will provide
+  * A Java SE based implementation with minimal features and dependencies.
+  * A Java EE extension module for integration with Java EE and Apache Deltaspike.
+  * Once Java ME supports Lambdas, default methods, method references and functional interfaces
an implementation targeting Java ME should be provided as well.
+  * Extension modules for different features.
+  * Adapter/inter-operation modules for other configuration solutions including Apache commons-config

- Properties can be read from files, classpath resources, or any accessible URI in any format.
- Extensions (custom formats and resource locations) can be provided by according SPIs easily.
- 
- Additionally configuration providers can be implemented as ''environment aware'', which
allows
- to dynamically returns different configuration trees, based on the current runtime environment.
- Hereby the environment is as well based on a simple key/value model, which additionally
supports
- child/parent relations between environments.
- 
- Finally with `Configuration` the API for configuration provides higher level
- features, such as type safe access and functional extension points, By default supporting
all common data types
- from the Java platform, including a representation for configured collection data. Well
defined extensions
- allow to adapt any target type required, as well as easily support more advanced features
such
- as templates, secured views, multi-valued validation schemes, en-/decryption or other.
- 
- By default configuration (and property providers) are designed and implemented as indirectly
- mutable types, providing thread-safe, unsynchronized and therefore fast access to configuration.
- Mutabilty is ensured (if supported), by creation of a mutable ''builder'' using a final
`commit()`.
- The API allows to listen to changes on a global as well as on a local, configuration based
level.
- It is also planned to support remote configuration change propagation scenarios.
- 
- Overall the API should be easy to learn, with a minimal set of artifacts to be know by the
developers.
- The API then can be implemented by different third parties using Tamaya's SPI. Tamaya itself
will provide a 
- lean, flexible, enterprise friendly implementation as well, with a minimal set of third
party dependencies.
- If possible an implementation executable on Java ME should be provided as well.
  
  == Background ==
  There is a global initiative running now for about a year lead by Anatole Tresch (Credit
Suisse)
  with the target of standardizing configuration in Java EE and SE. Due to several reasons
it
  seems currently most sensible to start an OSS project on the topic to join forces that actively
  want to contribute to the project. It is highly probably that standardization will be restarted
- at a later point.
+ at a later point once we have a widely used Apache standard.
- For further information you may look at his blog at javaeeconfig.blogspot.com .
+ For further information you may look at http://javaeeconfig.blogspot.com .
  
  == Rationale ==
- Configuration is one of the most cross-cutting concerns, which still lacks of any standard,
especially
+ Configuration is one of the most cross-cutting concerns, which still lacks of a standard.

- beside Java EE. Nevertheless Java EE is currently (EE7) in most areas strictly only configurable
during
+ Java EE is currently (EE7) in most areas strictly only configurable during
  build time of the deployed artifacts. Especially dynamic provisioning of resources or runtime
configuration
  is not supported and in many cases impossible to add without tweaking the underlying application
server.
  On the other hand running two separate configuration solutions for Java EE and Java SE as
well make no or
  little sense. So it would be important we have a unified configuration model at hand, that
is flexible enough, so
  
-  * it can be used in Java SE and EE
+  * it can be used in Java SE, EE and ME
   * it can support contextual behaviour (like in Java EE and multi-tenancy/SaaS scenarios)
   * it provides a uniform API, regardless, if its used in SE or EE scenarios
   * it supports existing APIs, e.g. `System.getProperties, java.util.preferences` in SE and
`CDI, JNDI` in Java EE
@@ -85, +64 @@

  
  
  == Initial Goals ==
- There is an existing code base implementing a significant part of the features mentioned
already at
- https://github.com/java-config , which will be moved into the incubator.
- After having etablished the project infrastructure, it would be important to
- release an initial version soon, so we can ensure adoption is pushed quickly forward
- and the project's member can also bring in ideas and enhancement proposals
- to the current running Java EE 8 JSRs.
+ 
+ The initial goals of the Apache Tamaya project are to:
+ 
+  * Setup the governance structure of the project
+  * Receive code donations from https://github.com/java-config
+  * Ensure all donated code is appropriately licensed under the Apache License
+  * Merge and rename code to reflect new project name
+  * Define the project modules and structure (API, implementation modules, adapter modules,
examples)
+  * Provide examples demonstrating feature usage
+  * Produce release/s based on a schedule created by the PMC
+  * Attract contributions from the greater Java community
+  * Setup collaboration with other projects and the JCP to bring in ideas and enhancement
proposals, e.g. to Java EE 8
  
  == Current Status ==
  There is an existing running code base implementing a significant part of the features mentioned
already at
@@ -250, +235 @@

  
  
  == External Dependencies ==
+ 
+ The following external dependencies have been identified:
+ 
+ The core functionality will be dependent on/use
+  * Apache Maven - Java based build tool - Apache License 2.0, (non-runtime)
+  * Shrinkwrap - Java deployment packaging - Apache License 2.0 (non-runtime)
+ 
+ The parts requiring EE will probably make us of
+  * Arquillian - Java EE integration testing framework - Apache License 2.0, (non-runtime)
+  * various Java EE API packages - all Apache License 2.0 (non-runtime)
+ 
  The API part of the current initial source is completely standalone (it does not have any
further dependencies than
+ the JDK). The SE 8 based part does mainly depend on Apache commons-logging for logging.
- the JDK). The SE 8 based part does mainly depend on sl4j for logging and uses Weld SE for
testing a possible
- CDI integration.
  
  
  == Cryptography ==
@@ -271, +266 @@

   * Commits for Tamaya will be emailed to `commits@tamaya.incubator.apache.org`.
  
  == Git Repository ==
- The project will be hosted at https://git-wip-us.apache.org/repos/asf/incubator-tamaya.git
+ It is proposed that the source code for the Apache Tamaya project be hosted in the Apache
Git repository, under the following directory:
+ 
+  * `incubator/tamaya/`
  
  == Issue Tracking ==
- JIRA Tamaya (TAMAYA)
+ The following JIRA project would be required to track issues for the Apache DeltaSpike project:
+ 
+  * `DELTASPIKE`
  
  == Other Resources ==
  None.

---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message