tamaya-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anat...@apache.org
Subject [3/6] incubator-tamaya git commit: Reorganized doc module for easier documentation.
Date Mon, 12 Jan 2015 22:32:58 GMT
diff --git a/docs/usecases/se/simple-access.adoc b/docs/usecases/se/simple-access.adoc
new file mode 100644
index 0000000..bc1bf59
--- /dev/null
+++ b/docs/usecases/se/simple-access.adoc
@@ -0,0 +1,18 @@
+=== Simple Access
+Users want to be able to access configuration in a unified way both in SE and EE. EE may
provide additional
+mechanism, such as injection, but the SE mechanisms should work as well, so any code written
in SE is fully
+portable to EE as well.
+This can only be achieved by providing a static accessor, e.g.
+Configuration config = Configuration.current();
+The call above should work exactly the same in EE. To enable this the static call must be
delegated in the
+internals of the singleton, depending on the runtime. In EE the executing component can behave
+or even be loaded within the CDI environment (at least for post loading, application runtime
aspects, but not earlier).
+Additionally in EE it should also be possible to inject Configuration, which gives you the
same results as the call
+private Configuration cfg;

diff --git a/docs/usecases/se/simple-property-access.adoc b/docs/usecases/se/simple-property-access.adoc
new file mode 100644
index 0000000..81fb879
--- /dev/null
+++ b/docs/usecases/se/simple-property-access.adoc
@@ -0,0 +1,9 @@
+=== Simple Lookup of Properties
+Users just want to create a configuration ad hoc, from given property files. The
+files could be locally in the file system, on the classpath.
+Tamaya should provide a simple Java API for accessing key/value based configuration. Hereby
users want to access
+properties as simple String values.
+Hereby returning Java 8 Optional values must be considered as well, instead of returning
\ No newline at end of file

diff --git a/docs/usecases/se/templates.adoc b/docs/usecases/se/templates.adoc
new file mode 100644
index 0000000..0aff6c3
--- /dev/null
+++ b/docs/usecases/se/templates.adoc
@@ -0,0 +1,11 @@
+=== Configuration Templates
+Users want to be able to let Tamaya implement an interface template based on configuration.
+This use case is pretty similar to the injection use case. Basically the values are not injected,
+but cached within the template proxy returned, e.g. as +DynamicValue+.
+Similarly it could even be possible to define callback methods (default methods)
+or register listeners to DynamicValue instances returned.
+Templates hereby can easily be managed, but provide a excellent mechanism to provide type-safe
+to clients in a very transparent way. Details can be controlled by using the same annotations
as for
+normal configuration injection.

diff --git a/docs/usecases/se/type-safe-properties.adoc b/docs/usecases/se/type-safe-properties.adoc
new file mode 100644
index 0000000..e71d31c
--- /dev/null
+++ b/docs/usecases/se/type-safe-properties.adoc
@@ -0,0 +1,10 @@
+=== Type Safe Properties
+Users just want to access properties not only as Strings, but let Tamaya do the conversion
to the required
+or the configred target type. By defauklt all java.lang wrapper and primitive types should
be supported, but also
+other common types like date/time types, math numeric types and more.
+It must be possible that users can register their own custom types.
+Finally users also want to be able to dynamically provide or override type adaption (conversion),
when reading a value,
+for a certain key/value pair.
\ No newline at end of file

diff --git a/docs/usecases/se/value-placeholders.adoc b/docs/usecases/se/value-placeholders.adoc
new file mode 100644
index 0000000..57857a8
--- /dev/null
+++ b/docs/usecases/se/value-placeholders.adoc
@@ -0,0 +1,8 @@
+=== Value Placeholders
+Users just want to to be able to add placeholders to the values of configuration (not the
keys). The mechanisms for
+resolving the placeholders hereby should be not constraint to one single lanmguage like EL.
Instead of different
+replacement strategies should be selectable, e.g. by prefixing an expression with the name
of the resolver that
+should do the work (eg +"blabla ${env:HOME} using Java version ${sys:java.version}."+.
+This allows resolution mechanism to be isolated easily and also allows to use simpler mechanisms,
if no more complex
+ones like EL are required. This is especially useful to deal with low resource environment
like ME.

diff --git a/docs/usecases/usecases.adoc b/docs/usecases/usecases.adoc
new file mode 100644
index 0000000..8b651fa
--- /dev/null
+++ b/docs/usecases/usecases.adoc
@@ -0,0 +1,44 @@
+= Apache Tamaya -- Use Cases
+:name: Tamaya
+:rootpackage: org.apache.tamaya
+:title: Apache Tamaya
+:revnumber: 0.1-SNAPSHOT
+:revremark: Incubator
+:revdate: November 2014
+:longversion: {revnumber} ({revremark}) {revdate}
+:authorinitials: OBF
+:author: Oliver B. Fischer
+:email: <plexus@apache.org>
+:source-highlighter: coderay
+:website: http://tamaya.incubator.apache.org/
+:toc-placement: manual
+:encoding: UTF-8
+== Use Cases for Java SE Environments

View raw message