We have a similar requirement that there is a notion of a runtime environment, whether it be a server runtime or a test case runtime, and that environment needs access to configuration information.
What information is needed?
In the case of 384, this would contain configuration for components that spans individual deployments. For example, a default context path or server port for the soap component.
In the case of 434, this would contain information that spans test cases. For example, to resolve port conflicts when running the jbpm test cases which require starting up a jbpm/mina task server and client, when that user might already be running things on those ports. Or heck, even in a shared build environment where those ports are not available.
In both cases, this could also provide a better way for specifying which activator implementations to use, rather than the current ServiceLoader approach.
How should the information be structured?
We already have a data structure for configuration: org.switchyard.config.Configuration. Currently, we use this deployment-level component configuration, but it is by no means dependent or tied to that usecase. It is a generic, flexible, heirarchal configuration structure which I see no reason to not reuse.
The more debatable question is whether or not we use org.switchyard.config.model.Model(s) to wrap the Configuration(s), as we normally do for deployment-level component configurations. The benefits of using models is two-fold:
- Models can be validated with schemas, Configurations cannot.
- Domain-specific methods can be added to Models to increase ease-of-use. For example, model.getPort() vs. Integer.parseInt(config.getAttribute("port")). Note: I'm considering adding helper methods to Configuration to make this easier, so it might become a moot-point. For example: config.getInt("port").
Even if we only have a model at the root of the runtime environment, maybe called SwitchYardEnvironment, that might afford us to add validation in the future without having to change a hundred method signature calls - even if we don't define a schema for the environment this early on, if ever. I think this would be a Good Idea.
How should the information be created?
This would be dependent on the runtime itself. I believe we'd have different SwitchYardEnvironmentBuilder implementations, one for AS6, one for AS76, one for OSGi, one for JUnit tests, and any other environment we might someday run within.
My point is that our code:
- Should not have to know how to handle different kinds of structures representing configuration data. We already have that, and we should use it.
- Should not have to know how that configuration data was built.
How should the information be provided?
This, again, would be dependent on the runtime itself.
- Maybe our test cases can will have a new method on SwitchYardTestKit called getEnvironment()
- Maybe our test cases can have a SwitchYardEnvironment auto-injected via annotation.
- Maybe in an AS6 or AS7 runtime, one can access SwitchYardEnvironment via JNDI or the AS7 modules functionality.
- Mabye in an OSGi runtime, the SwitchYardEnvironment is provided by the ConfigAdmin functionality.
I'm sure other implementations can be thought of, but I'm not stuck on how this is done.