portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Dam <d....@hippo.nl>
Subject Re: [RT] Spring Configuation
Date Mon, 19 Nov 2007 17:39:58 GMT
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:cziegeler@apache.org] 
> Sent: Friday, November 16, 2007 12:27 PM
> To: jetspeed-dev@portals.apache.org
> 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
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
> 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: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message