portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [RT] Spring Configuation
Date Mon, 10 Dec 2007 15:08:57 GMT
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?

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


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


Mime
View raw message