gistfile1.md

Nexus Configuration Framework

History:

• initial inspiration was Plexus Component configuration (XML is mapped to Component fields in type-safe manner)
• extra requirement was to make it two-way as opposed to Plexus "one way": Component field change should be persisted back to model and it's persisted representation when needed.

Goals:

• maps corresponding hierarchical space to correspondent SISU Components
• is model persistency technology independent
• handle version-wise upgrades
• implement "two phase" commit: if multiple components are modified, the changes has to be applied in "all or nothing" manner (to not end up with inconsistent configuration)
• due to "server" nature, configuration is applied at once, changes are not "visible" until they are applied (to not change behavior for concurrent threads)
• configuration WRITE ops might be slow, but configuration READ ops (needed to execute a request) must be fast
• offers type-safe access to configuration (in contrast to direct access to model, like enum vs string, etc)

Goals as they are implemented:

• maps corresponding nexus.xml XML nodes to correspondent SISU Components
• Model is plain POJO (Modello generated), uses XML persistency format, is defined as nexus.xml
• Handle version-wise upgrade easily using Modello converter
• manually implemented, but in dumb way: two model instances are used original and changed. Component is "dirty" when it has both instances (non-dirty has changed as null)
• manually implemented
• currently no sync happens and multiple threads doing configuration WRITE overlap with each other (and will stay as such if state is still valid)
• manually implemented

Assumptions:

• an instantiated (constructed) component is in "valid" state
• component configuration might be altered by a type-safe setter on it
• component prevents bad (invalid) transitioning (from "valid" to "invalid" state)
• hence, the overall model kept in memory (the one in-effect currently) is always "valid"

Requirements:

• a content requesting thread should see one "snapshot" of a configuration from the moment it enters to the moment it exists (should not pick up applied changes in the middle?)
• a configuration requesting thread should perform same as above, should deliver a "snapshot" (currently it will also pick up changes in the middle)
• a configuration modifying thread should either: perform and successfully apply all the changes it has (win), or fail (loose) due to changes done by some other concurrent thread
• configuration would need some designator, generation or anything that would allow us to do this, does not need to be persisted, might be reset on boot (ie. generation as int starting with 1 after nexus booted)