Terracotta Integration Modules Feature Discussion
 |
Much of this discussion has already been implemented in the current Terracotta Integration Modules facility. --Orion. |
This discussion space is for configuration modules identified in JIRA issue CDV-49
. While in technical circles (OSGi/Eclipse) these are referred to as bundles, users dub this functionality 'modules.'
Project members
- Eugene Kuleshov
- Antonio Si
- Gary Keim
- Juris Galang
- Tim Eck
Goals
- Ease of end-user configuration (see JIRA issue CDV-49)
- Modularization and appropriate grouping of existing instrumentation
- Publicize the mechanism used so that 3rd parties can write their own configuration bundles
- Inline configuration (a la Spring) for bundles that require it; this will not be done in this first version
Strategy
API implementation
After letting some discussions finally sink in with Eugene, Gary and Antonio, the proposed approach (subject to review) for the API and bundle workings is the following:
- Lose the changes made in com.tc.bundles
- Configuration now allow to declare modules and module repositories
- Create an instance of StandardDSOClientConfigHelper
- Load/create the module/bundle layer and "publish" the StandardDSOClientConfigHelper instance to it
- Loop through the specified modules in the configuration
- As each module/bundle is loaded, it can lookup StandardDSOClientConfigHelper and manipulate it
- Loader also checks for the optional Terracotta-Configuration header in the bundle manifest that can refer to xml-based configuration. If header is not specified, loader also checks for terracotta.xml at the root of the bundle. If the config file is found it is loaded into the StandardDSOClientConfigHelper.
- Proceed as normal; StandardDSOClientConfigHelper should now have all the info it needs
It should be noted that this is a first cut, not necessarily suitable for general public use in this release. As we move forward in coming releases, interesting parts of StandardDSOClientConfigHelper can be re-factored into a nicer interface, which at some point can be thoroughly documented, re-factored, and otherwise made nice for people to use.
We may need to add some support to runtime to environment to allow running and debugging modules without creating jars. Core DSO already have similar support based on the project classpath and we should be able to hook into that. For example, we can search for the manifest files in the classpath, then register projects with those manifests for all matching plugins declared in the configuration and then also load regular module jars from the declared repositories. The prerequirement for this is to have all required modules in the project classpath, which shouldn't be a big issue.
Platform
We are using embedder Knoplerfish OSGi implementation as a runtime.
Tasks
- on hold for now
(Antonio, Eugene, Nat) Design/create an API for configuration modules to implement, such that they can participate in the following configuration/instrumentation details:
- Identifying roots and locks,
- Identifying distributed method calls
- Identifying classes that need to be instrumented
- Boot jar requirements; identifying which system classes need instrumentation and failing the application if that requirement is not met
- Identifying custom class transformers
- Identifying AspectWerkz aspects
- Identifying classes that need to be made available in the application namespace (i.e. classes that are used by aspects or introduced by the custom class transformers)
- Other custom settings, i.e. web application names, configuration specific to Spring
- (Nat) Configuration file changes to specify bundles to be included, for example (this is only a sketch of what we might need):
....
<modules>
<repository>file:///usr/share/terracotta/modules</repository>
<repository>file:///home/scott/.tc-modules</repository>
<repository>http://www.terracotta.org/modules</repository>
...
<module name="my-module" version="1.0"/>
<module name="some-other-module" version="7.2"/>
...
</modules>
....
Resources
Notes
Per JSR-277 we are using the term 'modules' vs. 'plugins' or 'bundles.'
