Thorsten Scherler wrote:
> Ross Gardler escribi??:
> > Mathieu Champlon wrote:
> >
> > > 3/ configuration variables precedence order
> > >
> > > It seems from reading ForrestConfModule#initialize that configuration
> > > variables come from four different sources, in this order (the first
> > > defined wins) :
> > > . system properties
> > > . xml configuration files
> > > . property configuration files
> > > . plugin xml configuration files
> > >
> > > System properties are defined in the ant scripts as the properties
> > > starting with either 'forrest.' or 'project.', including -D properties
> > > from command-line and properties loaded from files with <property
> > > file=.../>.
> > > Therefore all configuration variables defined in property files loaded
> > > by forrest.build.xml are accessible as system properties in
> > > ForrestConfModule (well actually not all of them, because 'proxy' isn't,
> > > but it's used only in ant scripts).
> > > So there is no need to reload ${project.home}/forrest.properties in
> > > ForrestConfModule#initialize.
> > > Moreover, as the system properties are loaded at the end but replace all
> > > other properties (in ForrestConfModule#loadSystemProperties),
> > > configuration values from xml files are actually replaced by values from
> > > property files.
> > >
> > > So the actual precedence order is :
> > > . command-line properties
> > > . property configuration files
> > > . xml configuration files
> > > . plugin xml configuration files
> > >
> > > What I suggest is to refactor ForrestConfModule#initialize so that it
> > > clearly reflects all this, simplifying it at the same time, mostly by
> > > removing the unnecessary code and re-arranging the loading order.
> >
> > That all sounds fine by me.
>
> You forgot the ones from forrest-core.xconf.
>
> ForrestConfModule does not implement configure(...) meaning it will use
> the one from super (DefaultsModule). This is adding properties from the
> configuration (which are different for defaults vs. project).
There is also another way to add properties.
Cocoon has a new properties system which we have not
been using yet. The version of Cocoon that we are
currently using is not the most recent, but it includes
an implementation which does work.
It reads properties from a set of configuration files
under WEB-INF/properties/ (in our version of Cocoon).
These properties can then be used in Cocoon's xconf
and sitemaps.
http://cocoon.zones.apache.org/daisy/documentation/g1/1162.html
(That is for the current Cocoon trunk.)
See http://issues.apache.org/jira/browse/FOR-917
-David
