Hi,
such a configuration framework could be useful, but I think what Carsten
is suggesting here goes much further than providing a framework for
injecting Spring properties from different configuration sources. Please
correct me if I'm wrong. It is *part* of what the Cocoon Spring
configurator does, but it also provides a bean definition overriding
functionality and bean registry functionality. I think it would be
useful to standardize these functionalities in one project. There could
be even more "common" features which can be added. There are several
advantages to such a framework:
- reduce the development time for setting up the Spring configuration
(obviously)
- reduce the learning time for Apache developers coming from different
projects.
- a best-of-X-worlds solution: evaluate the Spring configuration
experiences / troubles of different projects and take the best ideas
from each project, starting with Jetspeed and Cocoon :)
Just another idea from my side for such a common Spring configurator:
make it possible to use N layers of bean definitions, each layer
overriding the bean definitions of the previous layer. We do this in
jetspeed now with 2 layers. But you could imagine the usage of 3 layers
or more (please replace "jetspeed" with your favorite project here) :
1. the default jetspeed bean definitions
2. bean definitions for a company-specific jetspeed distribution
3. bean definitions for a project-specific implementation for the
company-specific jetspeed distribution
Although personally I think too many layers will make reading the bean
definitions too difficult, at least you leave the choice to the developer.
It might also proof useful to have a default configuration engine which
reads properties from pre-defined locations (convention over
configuration). This is similar to the approach the Cocoon Spring
Configurator takes, but ofcourse the paths to the locations should be
project independent (i.e. replace 'cocoon' with something neutral). In
this way you know where to look for Spring properties files in every
Apache project.
By the way, the dynamic registry of the Cocoon Spring Configurator is
very similar to a bean registry I used before.. It seems like the wheel
is being reinvented a lot :)
Dennis
Boyce, Keith Garry wrote:
I suggest the following which I have used successfully for a while.
Rather than a particular solution it offers an integration point with
different configuration engines.
http://forum.springframework.org/showthread.php?t=12271
I use it with jconfig.
-----Original Message-----
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: Friday, November 16, 2007 12:27 PM
To: [email protected]
Subject: [RT] Spring Configuation
Just sitting in Ate's and David's presentation about Jetspeed I had the
feeling that the stuff you did for Spring configurations (like
overriding etc.) is similar to something we did in the Cocoon project.
We have there a Spring configurator which is absolutely independent of
Cocoon and provides support for property handling (we call settings),
overwriting of configurations, automatic configuration etc.
See here for some documentation:
http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurat
or/1.0/1304_1_1.html
Now, although the project is current hosted at Cocoon it has a much more
common nature. This is just an idea out of my head, but perhaps we could
work on a common configurator which is then used by several projects at
Apache? This would make the live of users perhaps a little bit easier as
they can apply the configuration knowledge for several projects.
This does not imply that I want to force Jetspeed to use our Cocoon
stuff, of course.
WDYT?
PS: Don't expect an answer from me in the next three weeks as I'm on
vacation, but I wanted to throw this in now :)
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is a PRIVATE communication.
If you are not the intended recipient, please do not read, copy
or use it and do not disclose it to others. Please notify the
sender of the delivery error by replying to this message and then
delete from your system. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
