Grzegorz Kossakowski skrev:
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 would restrict the use of configuration to use within the same module.
So it depends.
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?
No strong opinion about that. If a couple of beans works togther or are
of the same "kind" it seem natural to put them together in one file.
Otherwise not. What is your opinion?
/Daniel
