You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/03/23 23:03:25 UTC
Configuration Requirements, merged, ordered
Combination of Jim's mail and mine...
I didn't have an ordering in mine so I took his.
1a Users must be able to provide custom data values for configuration
properties and references using any Java Object.
1b Users must be able to provide mechanisms that construct those Objects
from XML artifacts using a binding technology of their choice.
2a We need to provide mechanisms that make it easy for extension
developers extend the configuration model. They must be
able to contribute configuration information specific to their
extension.
2b Manipulating the model should follow Java idioms as closely as
possible. The implementation should use technologies familiar
to both Tuscany developers and to other open source developers
who may be interested in contributing to the project.
2c Extension providers must be able to provide handlers for XML
artifacts using technologies commonly accepted and familiar
in open source environments.
3 Operation in a variety of deployment environments. The model
must remain easy to use/extend in different classloader
hierarchy scenarios. It must easily support isolation between
Host, Tuscany and application classloaders.
4a It must be able to load configuration from sources other than
XML. Configuration may be stored in other forms e.g. as
returned from a registry.
4b It must be able to construct configurations programmatically.
This is intended both to support our test/bootstrap needs but
also to support users who wish to test components that rely
on container-provided infrastructure.
5a The implementation should be easily understood by Java
developers wanting to contribute to Tuscany.
[[ JNB I would move this higher ]]
6 We must be able to support multiple versions of serialized
configuration files - for example, we must support both 0.9
and 1.0 revision SCDL files.
7 The implementation must be able to handle large configurations (1000
components) with reasonable performance and memory consumption and
linear scalability.
8 The model should allow us to easily accommodate spec changes.
Thoughts?
--
Jeremy