New approach for providing configuration data (properties) is available

[Torsten Juergeleit]

Sculptors current configuration approach (creating chained Properties instances in "PropertiesBase") is somewhat limited:
It's only usable after initialization of the corresponding Guice injector. So it can't be used within a Guice module (in our case "ChainOverrideAwareModule") for configuring the binding (e.g. the properties "defaultOverridesPackage" and "cartridge").


In #94 a new approach for providing configuration data in a generic Guice-friendly manner was implemented:

• The new Maven project "sculptor-generator-configuration" provides a generic "ConfigurationProvider" interface for reading configuration values and its extension "MutableConfigurationProvider" for manipulating the configuration values.
• There're a few implementations for these interfaces - FileResourceProperties-based ones and a SystemProperties-based one. To allow chaining multiple ConfigurationProvider a CompositeConfigurationProvider is provided as well.
• For wiring the ConfigurationProvider implementions needed for Sculptors properties files the Guice module "ConfigurationProviderModule" is provided. Here the cascaded-Properties approach from "PropertiesBase" is implemented via CompositeConfigurationProvider.
• In addition to be chained in "CompositeConfigurationProvider" the ConfigurationProvider which holds the default configuration (loaded from "default-sculptor-generator.properties") is exposed as "MutableConfigurationProvider" instance. For identifying this configuration provider it's annotated as named binding "Mutable Defaults". This named MutableConfigurationProvider is injected in "PropertiesBase" for modifying the default values with the inherited default values.
  
• To support configuration data in Sculptors Guice module "ChainOverrideAwareModule" we need a two-phase Guice wiring approach: By using "ConfigurationProviderModule" in a separate Guice injector the bootstrap configuration data is maintained. This special bootstrap injector (with its bootstrap configuration data) is used as a child injector for Sculptors chain-override extension mechanism implemented in "ChainOverrideAwareModule". This two-staged injector handling is hidded in "ChainOverrideAwareInjector".

So with the new configuration approach the injector for Sculptors chain-overriden templates is created via "ChainOverrideAwareInjector.createInjector()". In "PropertiesBase" this injector injects the aforementioned "CompositeConfigurationProvider" instance and the "MutableConfigurationProvider" instance named as "Mutable Defaults".


With this configuration approach the support for providing new or changing existing default properties via Sculptor cartridges (as described in #116) should be feasable as well. As a proof of concept the refactoring of Sculptors mongodb support into a cartridge (as mentioned in #51) can be used.

/Torsten

[Torsten Juergeleit]

With this configuration approach the support for providing new or changing existing default properties via Sculptor cartridges (as described in #116) should be feasable as well. As a proof of concept the refactoring of Sculptors mongodb support into a cartridge (as mentioned in #51) can be used.

How to add default properties in a cartridge is shown in the class MongoDbProperties introduced in #51. Here the method "initDerivedDefaults()" is called during Guice wiring. This methods gets injected a "MutableConfigurationProvider" instance named as "Mutable Defaults" holding Sculptors default properties.

We should come up with a more generic approach: How about a abstract base class implementing the strategy of default property initialization by loading data from a cartridge-specific properties file?
WDYT?

/Torsten

[Ron Smith]

This all sounds good, and being able to pull the cartridge-specific property defaults into the cartridge will help us continue modularizing Sculptor.

The approach of having an ABC that loads data from a cartridge-specific properties file sounds good too.

--Ron

[Torsten Juergeleit]

I'm glad you like it.

But I'm not sure about the predictability of the current approach (injecting the named MutableConfigurationProvider). Here it's up to the order Guice is binding / wiring the objects.

To get a definite order of deriving default properties of all cartridges we could use the order defined in the property "cartridges".

A possible approach for this is by providing a @ChainOverride extension of "Properties.initDerivedDefaults()" within every cartridge.

WDYT?

/Torsten