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:[EMAIL PROTECTED] > 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 > [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] > > -- Carsten Ziegeler [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
