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