Apache Tamaya - Possible Tasks

2.1. Purpose of this Document

The document should help to organize people and ideas around the Apache Tamaya Library. It list possible features, ideas and tasks that need to be done. Everybody can have a look at and see, where hos contribution and capabilities would fit best.

3.1. Metadata Model

Currently MetaInfo models metadata as a separate constuct. It has been shown that this leads to more complex handling when creating composites and makes the API overall more complex. The idea is to model metadata as simple key/value pairs, that are part of the provider/configuration data as well, but handled separately. Metadata hereby is identified by a starting '_' character in its key. For example refer to the following configuration properties:

a.b.Foo=foo
a.b.Bar=bar
a.AnyOther=whatelse
Something=none

Now we can model meta-data as follows:

[a.b].info=An area info
[a.b.Foo].auth=role1,role2
[a.b.Foo].encrypt=PGP
[a.b.Foo].sensitive=true
[].info=This is a test configuration example.

The above would model the following:

• The area a.b has the meta property info.

• The entry a.b.Foo has three meta properties auth,encrypt and sensitive. These could be interpreted by a security view and used to encrypt the values returned by the configuration instance, if not the current user has one of the specified roles.

• The last meta data defines an attribute info for the whole provider/configuration (the root area).

Given that the overall entries would be as follows:

[a.b].info=An area info
a.b.Foo=foo
[a.b.Foo].auth=role1,role2
[a.b.Foo].encrypt=PGP
[a.b.Foo].sensitive=true
a.b.Bar=bar
[].info=This is a test configuration example.
a.AnyOther=whatelse
Something=none

The current MetaInfo class could be adapted, so it is reading data from the underlying configuration/provider, instead of its own datastructure. This would make a later mapping of configuration and its metadata into DB table, JSON etc, much more easier. The providers on the other side may suppress any metadata from ordinary output, such as toString(), Similarly accessing metadata using the official config API (get, getOrDefault, getAreas etc) should be disabled. The MetaInfoBuilder must probably as well adapted or redesigned.

3.2. Management Client

A nice web-based client to manage configuration data would be nice as well. This also includes a UI for creating new configurations.

3.3. Mapping Configuration to a Database

A flexible mechanism should be implemented that allows the use of databases (SQL/JPA as well as non-SQL) for storing/retreiving/managing configuration:

• JPA, Hibernate

• MongoDB

• …​

3.4. Integration with Jigsaw

Once Jigsaw is mature and in a usable (still early) stage, examples are to be created and tested, where OSGI is used as the basic runtime platform, e.g. Apache Felix, but as well others.

4.1. Configuration Distribution Policies

Different configuration distribution policies should be defined any implemented, e.g. distributed cache, restful services, web services, EJB/RMI calls, asynchronous queues, publish/subsribe models, …​

4.2. Preferences Support

Write a PreferencesFactory for java.util.preferences.

5.1. Integration with Deltaspike Config

Integration with Deltaspike Config should be implemented and discussed with Deltaspike guys.

5.2. Integration with Spring

A {name} module should be created that allows Spring to be used either as client or configuration provider.

5.3. Integration with Jetty

A {name} module should be created that allows a Jetty instance to be deployed and started that is (completely) configured based on configuration server.

5.4. Integration with Tomcat

A {name} module should be created that allows a Tomcat instance to be deployed and started that is (completely) configured based on configuration server.

5.5. Configuration of Java EE

In the Java EE area there would be several options:

5.6. Configuration of Application Servers (administrative resources)

It should be possible to start a application server instance remotely and configure all administrative resources and the deployments based on the configuration service, server to be considered maybe

• Wildfly

• IBM

• Weblogic

• Glassfish

• Apache Geronimo

5.7. JNDI Support

Write a JCA adapter to provide configuration data through JNDI.

6.1. Maintenance Mode Servlet Filter

Provide a servlet filter that is capable of switching to maintenance mode, based on configuration. Similarly also a forwarding servlet could be useful, wehere only request based on configuration are forwarded, other might be rejected or dropped as configured.

6.2. Dynamic Camel Routes

Provides dynamic (configurable) Camel routes, e.g. usable within ServiceMix or standalone.

6.3. Dynamic CXF

Provides dynamic (configurable) CXF adapters, e.g. usable within ServiceMix or standalone.

6.4. Configurable Apache MQ

Provides an implementation for configuring Apache MQ.

6.5. Dynamic …​

Interested to see what other ideas are around. Let us know!