28 Mar
2009
28 Mar
'09
1:50 p.m.
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