portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [RT] Spring Configuation
Date Mon, 10 Dec 2007 17:46:48 GMT
Carsten Ziegeler wrote:
> Boyce, Keith Garry wrote:
>> http://spring-config.sourceforge.net/
>>
>> http://www.jconfig.org/
>>
>> spring-config + jconfig already works exactly as described. 
>>
> Hi, I looked at both, but I'm still not sure if this is what we're
> looking for. Can you give us an example which demonstrates how to use them?
Same here.
To me the above links seem only to enhance property resolving which is nice and might be useful
by itself, but is not dealing with the real problem: 
dynamic/conditional spring configuration from within spring definitions itself.

Regards,

Ate
> 
> Thanks
> Carsten
> 
>> -----Original Message-----
>> From: Carsten Ziegeler [mailto:cziegeler@apache.org] 
>> Sent: Monday, December 10, 2007 9:56 AM
>> To: Jetspeed Developers List
>> Subject: Re: [RT] Spring Configuation
>>
>> Ok, I'm back from vacation and thought about this a little bit more. I
>> think my old proposal (quoted below) is not needed and all we need is
>> something as Ate proposed: a xml schema extension for spring handling
>> conditionals.
>>
>> If noone has done looked into this yet, I'll have a look in the next
>> days if it's possible.
>>
>> Carsten
>>
>> Carsten Ziegeler wrote:
>>> Just a quick answer - I'm still on vacation but couldn't resist to 
>>> check mails... :)
>>>
>>> Ate Douma wrote:
>>>> The Cocoon Spring configurer (or something similar) could be used to 
>>>> make this more flexible/extended, although I agree with Dennis we 
>>>> might want to make that more "project" independent, e.g. not looking 
>>>> for cocoon specific folders like META-INF/cocoon/ etc., but that 
>>>> should be easy enough to do.
>>>>
>>> Oh, yes - that's currently "cocoon" but we used that to separate it 
>>> from "META-INF/spring" which is partially used by spring, and the 
>>> spring configurator is right now a sub project of cocoon :) If we 
>>> would somehow use this code, we could (and should) change that of 
>>> course. (Keeping compatibility for cocoon would be easy as well).
>>>
>>>> For the above situations, our current override solution, nor 
>>>> something like the Cocoon Spring configurer can provide a real
>> solution.
>>> Yes, and Cocoon needs a solution for this as well :) But currently we 
>>> haven't thought/discussed this yet...
>>>
>>>> I really wonder why such a conditional XML Schema extension isn't 
>>>> provided by Spring already. Of course, I haven't actually tried to 
>>>> write this yet, but it seems quite plausible to do so.
>>> I wrote several XML handlers for spring and I think this should be 
>>> rather easy to do.
>>> I thought about this a little bit. One key feature of all this is to 
>>> make the decision at run time (like you proposed) - there shouldn't be
>>> any build time decisions - this will keep the implementation free from
>>> using specific build environments like maven.
>>> Another idea I had was to use a directory layout (these are just rough
>>> ideas I haven't thought yet up to the end, but I wanted to throw them 
>>> in as early as possible), so for example something like 
>>> /META-INF/spring-config/*.xml  <- general beans 
>>> /META-INF/spring-config/optional/CATEGORY_A/foo.xml
>>> /META-INF/spring-config/optional/CATEGORY_A/bar.xml
>>>
>>> And then a property will define if for CATEGORY_A ("CATEGORY_A" is the
>>> name for the category) "foo" or "bar" is used. This could also be done
>>> using the xml handler (like we use currently for the cocoon spring 
>>> configurator), so you can write something like this in your own 
>>> spring.xml bean configuration:
>>> <configurator:settings>
>>>    <configurator:categories>
>>>      <CATEGORY_A>bar</CATEGORY_A>
>>>    </configurator:categories>
>>> </configurator:settings>
>>>
>>> Don't quote me on the exact syntax, but I hope this roughly makes my 
>>> ideas clear :)
>>>
>>> Okay, and now back to sunbathing for another week :)
>>>
>>> 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