| :jbake-type: page |
| :jbake-status: published |
| |
| toc::[] |
| |
| = Apache Tamaya - Possible Tasks |
| |
| :numbered: |
| |
| <<< |
| |
| == Introduction |
| |
| == What is Tamaya |
| |
| {name} is the Apache standard for flexible and powerful configuration. Objective is to provide flavors for |
| Java SE, ME as well as to ship with powerful features for Java EE and Cloud Solutions. All functions provided |
| is build on top of a small but very powerful, flexible and extendible API. This API is implemented by a core implementation, |
| which then can be extended or adapted for use in different runtime scenarios, such as SE, ME, EE, Spring, OSGi |
| and more. Similarly additional modules may be provided that help also existing solution to be plugged into |
| {name}, so you can start right away using {name} without having to rebuild/change your existing application. |
| |
| |
| === 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. |
| |
| |
| == Main Features |
| |
| === 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: |
| |
| [source,listing] |
| .Basic Properties |
| ---------------------------------------------------------------- |
| a.b.Foo=foo |
| a.b.Bar=bar |
| a.AnyOther=whatelse |
| Something=none |
| ---------------------------------------------------------------- |
| |
| Now we can model meta-data as follows: |
| |
| [source,listing] |
| .Metadata Properties |
| ---------------------------------------------------------------- |
| [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: |
| |
| [source,listing] |
| .Full Properties with Meta Properties |
| ---------------------------------------------------------------- |
| [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. |
| |
| |
| |
| === 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. |
| |
| === 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 |
| * ... |
| |
| |
| === 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. |
| |
| == Distributed/Remote Configuration Support |
| |
| === 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, ... |
| |
| |
| === Preferences Support |
| |
| Write a +PreferencesFactory+ for +java.util.preferences+. |
| |
| |
| == Third Party Integration |
| |
| === Integration with Deltaspike Config |
| |
| Integration with Deltaspike Config should be implemented and discussed with Deltaspike guys. |
| |
| === Integration with Spring |
| |
| A {name} module should be created that allows Spring to be used either as client or configuration provider. |
| |
| === 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. |
| |
| === 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. |
| |
| === Configuration of Java EE |
| |
| In the Java EE area there would be several options: |
| |
| === 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 |
| |
| ==== Configuration of Bean Validation |
| |
| * Add configurable validators. |
| * Configure bean validation based on configuration |
| * ... |
| |
| === JNDI Support |
| |
| Write a +JCA+ adapter to provide configuration data through JNDI. |
| |
| ==== Configure JSF |
| |
| Use the JSF +XML Document+ event to completely configure JSF. |
| |
| ==== Configure Web Services |
| |
| Provide a WebServiceProviderFactory that may be configured. |
| |
| ==== Configure JPA |
| |
| Provide an implementation that allows configuration of persistence units. Talk with JPA EG people to see if we can |
| get an SPI to hook in a stadardized way. |
| |
| ==== Configure EJBs |
| |
| Provide an implementation that allows configuration of EJBs and MDBs: |
| |
| * Register beans |
| * Unregister/disable beans |
| * Intercept beans |
| * Support Configuration Injection (in the worst case using a standard Interceptor, provide supporting artifacts to |
| help developers to achive this easily). |
| * Talk with EE8 Umbrella EG (Bill Shanon, Linda DeMichels) on a feasible SPI for EE8, if possible join the EG. |
| |
| ==== Configure ... |
| |
| Just think of any Java EE aspects that might be worth to be configured. If it can be done, e.g. by managing CDI managed |
| resources, it might be easy. For others it is a good idea to discuss things with our matter of experts... |
| |
| == Special Goodies |
| |
| === 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. |
| |
| === Dynamic Camel Routes |
| |
| Provides dynamic (configurable) Camel routes, e.g. usable within ServiceMix or standalone. |
| |
| === Dynamic CXF |
| |
| Provides dynamic (configurable) CXF adapters, e.g. usable within ServiceMix or standalone. |
| |
| === Configurable Apache MQ |
| |
| Provides an implementation for configuring Apache MQ. |
| |
| === Dynamic ... |
| |
| Interested to see what other ideas are around. Let us know! |
