Daniel Fagerstrom pisze: > I'm not so happy about "non local" use of abstract bean configurations. > AFAICS it doesn't work with spring-osgi where you have one application > context for each block. And there is no obvious way to export abstract > configurations between bundles. Also they make the configurations harder > to read and, IMO, unnecessarily abstract. > > I think that abstract bean configurations are OK, as far as they only > are used within the configuation file where they are defined. Otherwise > I prefer beeing a litle bit more verbose. And one can always use factory > beans and custom configurations for complicated configuration patterns.
Your arguments seems to be valid. I'll take them into account when creating new code. What about integration tests? Can I use configuration templates, there? >> >>> I also wonder >>> why you use camel case names for Spring config files instead of >>> following the name convention that all the rest of the Spring configs in >>> Cocoon use. >> >> I didn't know we have such convention; so what are the rules? > > First, all configuration files are prefixed with the module name. This > is because they are collected from the classpath > (classpath*:META-INF/cocoon/spring somwhere in the configurator code), > to a common global Spring application context. Because of that the file > names needs to be unique. > > Second, smallcaps and hyphens are used. E.g. cocoon-core-generators.xml. I see. Last question is about multiple bean declarations in one xml file. Do we think it's good or bad practise? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
