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

Reply via email to