+1 On Sat, Mar 28, 2009 at 14:50, Vincent Massol <[email protected]> wrote:

Hi,

So far we've been using plexus configuration mechanism in components.xml to define component configuration data. I'm proposing to drop this. Reasons: 1) This is trying us to plexus and is not generic enough for all IOC frameworks 2) It doesn't easily allow overriding config values (for ex if the user wants to override a value in a wiki page or in xwiki.properties file)

I thus propose 3 things: 1) to use our new xwiki configuration mechanism to store component configuration data 2) to have a META-INF/<module prefix>.properties file located in the module jar where <module prefix> is org.xwiki.rendering for example for the rendering module (we could also have a submodule if the module is split into several modules). The idea is that the file name needs to be unique across jars so that we can create uberjars later on if need be. 3) in general we shouldn't have component-specific config data and instead make the data as generic config data as much as possible and bound to the module's Configuration component instead.

For 1) and 2), it's very easy to do: - the component which requires config data need to have ConfigurationManager and ConfigurationSources injected and implement the Initializable interface and then call in initialize():

      this.configurationManager.initializeConfiguration(this, this.sourceCollection.getConfigurationSources(), <prefix>);

- store data using a FQN in META-INF/<module prefix>.properties, for example:

      org.xwiki.rendering.internal.macro.RealmMacroSource.priority = 10

In this example you would call initializeConfiguration with a prefix value of RealmMacroSource.getClass().getName().

3) is important because otherwise users will be able to override private config data and if the internal implementation changes the config data won't be valid anymore. The reason for 2) is to hide these config data from the users as much as possible since these are advanced config options that shouldn't normally be used. For example we would defined a default priority for macros but in some very exceptional cases the user would want to change the priority so that the macro executes at a different time for a given reason.

Another example if the velocity components which contain lots of data. I believe these data should be moved to a VelocityConfiguration component instead.

WDYT?

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne