portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [RT] Spring Configuation
Date Tue, 20 Nov 2007 18:21:07 GMT
I think that we might be hitting the limitations of spring as a  
component framework.  My understanding is that spring is great as a  
wiring framework for a single set of known components but does not  
provide much functionality for swapping or plugging in  
implementations (classes) or instances (spring beans) of services.  I  
think for this you need another level of component framework.    I  
really don't advise trying to write your own.  The frameworks I know  
about that would probably solve this kind of problem for jetspeed, in  
order of my familiarity with them:

1. geronimo gbean framework.  This definitely provides everything you  
would need but AFAIK has never been run embedded in an application  
and currently requires you to write down metadata for each  
component.  We can remove the latter restriction pretty easily but  
this is not a popular solution at the moment and would probably have  
too steep a learning curve.

2. osgi-spring.  I don't know much about this but osgi provides a  
pretty sophisticated classloader model and it combines with spring  
for component wiring.  I don't have any idea how or if component  
references between modules (bundles) get resolved or how you specify  
which bundles that provide a service you want  to use.  This seems to  
be getting more popular.

3. plexus.  I know virtually nothing about plexus or its capabilities  
but suspect it has a lot of the needed properties since it's used in  
maven for moderately similar purposes.

With any of these there may be odd interactions between the component  
framework jetspeed is using and the component framework used by the  
app server its running in.  In particular using the classloader  
structure provided by the app server may reduce inappropriate  
interactions.

thanks
david jencks

On Nov 19, 2007, at 9:39 AM, Dennis Dam wrote:

> 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
>


---------------------------------------------------------------------
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