Carsten Ziegeler wrote:
Ate Douma wrote:
Carsten Ziegeler wrote:
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.
That would be great!
I haven't had time to further investigate and search for possibly
already defined/discussed similar solutions (the spring forums especially).
So you're more than welcome to dive into it Carsten :)
I searched a little bit but didn't find similar solutions yet (but I'll
continue searching). In the meantime I looked at the namespace handling
stuff in Spring again, and it seems that's impossible to implement
conditional bean definitions with a namespace. The only working way
would be to wrap each bean definition with a condition, like
<bean name="general-db-service".../>
<cond:if test="o.a.jetspeed.db = hqsldb">
<bean name="...."/>
</cond>
<cond:if test="o.a.jetspeed.db = hqsldb">
<bean name="...."/>
</cond>
<cond:if test="o.a.jetspeed.db = derby">
<bean name="...."/>
</cond>
I looked into the Spring (2.5) custom NamespaceHandler feature this evening and I think it actually should be possible to wrap a bean definition, including with
its own namespace handling, with a custom namespace.
In a custom BeanDefinitionParser handling the condition logic you can "delegate" back parsing a nested bean definition as top level bean using the passed on
ParserContext its BeanDefinitonParserDelegate.
I don't have time left tonight to test this out, but I'll do that later this
week or this weekend.
If this works out as I expect, it should be easy to write an EL based condition
namespace bean parser providing just the features we need.
And if this holds true, I prefer to experiment with it from within the Jetspeed
code base itself for now.
Then, once all the features have been fleshed out and tested properly, we can see if we can promote it to a separate generalized Spring configuration tool like
the Cocoon Spring Configurator, or maybe even better, contribute it back to Springframework itself if they are interested.
Regards,
Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
