You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Carsten Ziegeler <cz...@apache.org> on 2007/12/10 15:56:27 UTC
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
Re: [RT] Spring Configuation
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Dec 10, 2007, at 7:08 AM, 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?
>
Yes, could everyone provide a few use cases demonstrating how their
Spring configuration works
Could someone explain to me how these solutions differ from / provide
added value over Spring JMX?
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [RT] Spring Configuation
Posted by Ate Douma <at...@douma.nu>.
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
Re: [RT] Spring Configuation
Posted by Carsten Ziegeler <cz...@apache.org>.
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
RE: [RT] Spring Configuation
Posted by "Boyce, Keith Garry" <Ke...@bcbsma.com>.
http://spring-config.sourceforge.net/
http://www.jconfig.org/
spring-config + jconfig already works exactly as described.
-----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
Re: [RT] Spring Configuation
Posted by Carsten Ziegeler <cz...@apache.org>.
Ate Douma wrote
> AFAIK both should be possible.
> The root level condition element has full control over parsing its own
> sub elements (and registering zero or more beans from it).
> And for sub elements which don't belong to its own namespace (like a
> <cond:when> which it can/should handle itself) it can delegate parsing
> those one by one to the ParserDelegate, thereby also supporting other
> namespaces.
>
Ah, that would be cool - by the time I wrote the stuff for the configurator
I couldn't figure out how to get this working, so I assumed it's not
possible :)
If you need any help, let me know - i'll have time next 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
Re: [RT] Spring Configuation
Posted by Ate Douma <at...@douma.nu>.
Carsten Ziegeler wrote:
> Ate Douma schrieb:
>> 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.
> As far as I know, you can wrap exactly one bean definition with one
> element. So this rules out, wrapping several bean definitions at once
> and it also rules out creating a nice xml syntax (like
> <cond:choose><cond:when>...). Wile the second one is not that important
> I think the first one is really annoying.
AFAIK both should be possible.
The root level condition element has full control over parsing its own sub elements (and registering zero or more beans from it).
And for sub elements which don't belong to its own namespace (like a <cond:when> which it can/should handle itself) it can delegate parsing those one by one to
the ParserDelegate, thereby also supporting other namespaces.
>
>> 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.
> Yeah, I'm fine with that.
>
> Carsten
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [RT] Spring Configuation
Posted by Carsten Ziegeler <cz...@apache.org>.
Ate Douma schrieb:
> 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.
As far as I know, you can wrap exactly one bean definition with one
element. So this rules out, wrapping several bean definitions at once
and it also rules out creating a nice xml syntax (like
<cond:choose><cond:when>...). Wile the second one is not that important
I think the first one is really annoying.
> 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.
Yeah, I'm fine with that.
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
Re: [RT] Spring Configuation
Posted by Ate Douma <at...@douma.nu>.
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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [RT] Spring Configuation
Posted by Carsten Ziegeler <cz...@apache.org>.
David Jencks wrote:
>
> On Dec 11, 2007, at 1:05 AM, Carsten Ziegeler wrote:
>
>> a) we define our own xml parser for these configuration files and this
>> parser filters the bean definition, so something like
>>
>> <bean name="general-db-service".../>
>> <cond:if test="o.a.jetspeed.db = hqsldb">
>> <bean name="...."/>
>> <bean name="...."/>
>> </cond>
>> <cond:if test="o.a.jetspeed.db = derby">
>> <bean name="...."/>
>> </cond>
>>
>> would be possible.
>>
>> b) We keep the various definitions in separate files, so in this example
>> we have three configuration files, one containing the general definition
>> for "general-db-service", one containing the hqsldb variant and one for
>> the derby stuff.
>
> Why do we need the general-db-service?
That's just an example to show that there are common beans that are
always required and others depend on the environment/configuration.
>
>> Then we need some external mechanism to specify when to read which
>> configuration files.
>>
>> In both cases we need something like the current cocoon spring
>> configurator that controls the parsing of the configuration files. I
>> think a) is more maintainable and flexible.
>>
>> WDYT?
>
> I'm a bit biased since in geronimo we have a system more like (b)
> (although we also have (a)). I think separate files together with a
> list of files to run will be much more convenient in the long term.
Can you give some pointers on how this is done in Geronimo?
>
> How are you planning to deal with configurations that need classes that
> don't come with jetspeed, i.e. extensible classloading?
I'm not planning to do anything additional for this. The classes have to
be accessible by the webapp classloader and then it works. So there is
no difference if the bean definition is in the global spring bean
definition configuration or inside a configuration handled by this
special mechanism.
I think in the long term, OSGi is the way to go - but I think that's a
different issue.
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
Re: [RT] Spring Configuation
Posted by Carsten Ziegeler <cz...@apache.org>.
Ate Douma wrote:
> To be honest, I'm a bit confused about what you are proposing.
> Without a concrete example and explanation what this rule language
> is/looks like and is supposed to do my gut reaction is this might be
> overkill for what we need.
> I definitely think we need as simple as possible solution using
> conventions and a language commonly known.
> That's why I tried to come up with a jstl/el type of example as its a
> standard and widly known language and the runtime evaluation should be
> easily embeddable.
> Defining or even dynamically loading our own custom language seems a bit
> too far fetched.
> But maybe I simply misunderstood your proposal and is it actually very
> simple, so it would be great if you could provide an example.
>
I haven't really thought that much about how the language should look
like. Now, the problem with your proposal is, that you want to embed the
languange inside a spring bean definition file - which is not possible
by just adding new elements with their own namespace. Of course, one
solution would be to pre-process each spring bean definition file, but
this would require that each and everyone uses a specific xml parser for
this (which does the filtering).
So, my proposal is to keep the conditions out of the spring bean
definition file, and create a simple rule file like (don't quote me on
the used element names, they should just give the idea):
<rules>
<rule id="database">
<when test="${pagemanagment='database'}">
<include src="optional/db-pm.xml"/>
</when>
<otherwise>
<include src="optional/castor-pm.xml"/>
</otherwise>
</rule>
<rule id="wsrp">
<if test="${wsrp.enabled}">
<include src="optional/wsrp-beans.xml"/>
</if>
</rule>
</rules>
This is basically the equivalent of your proposal, with the difference
of using an extra file for the conditions and putting the various
conditional beans in separate files.
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
Re: [RT] Spring Configuation
Posted by Ate Douma <at...@douma.nu>.
Carsten Ziegeler wrote:
> Okay, it seems that noone else has done these things already. At least I
> haven't found/seen any other examples.
Ok, although it still seems weird to me nobody else came up with the same idea (as well as a solution).
>
> As a starting point I would like to extend the Cocoon Spring
> configurator (CSC) with the below described logic. The CSC does already
> half of the required stuff (property and overwrite handling), so I think
> it makes sense to add the missing piece.
> As I already said, the CSC is hosted at Cocoon because this is the place
> where it all started. We can move it to whereever we think it needs to
> be *and* we can replace the search directory path "cocoon/something"
> with something more general.
> I hope everyone is fine with this for now?
Np for now.
>
> Ok, currently the CSC reads properties from
> META-INF/cocoon/properties and META-INF/cocoon/properties/{runningMode}
>
> The CSC reads spring bean definitions from
> META-INF/cocoon/spring/*.xml and META-INF/cocoon/spring/{runningMode}*.xml
>
> It also reads overwrite definitions from
> META-INF/cocoon/spring/*.properties and
> META-INF/cocoon/spring/{runningMode}*.properties
>
> I propose to add the following:
> We define a rule based language - we can either use existing rules
> implementations or create our own (xml) based one.
> The basic idea is to start with named rules that can test properties and
> include bean definitions.
> I would start with a simple xml based config file for these rules. The
> CSC reads the rules from
>
> META-INF/cocoon/spring/*.xrules and
> META-INF/cocoon/spring/{runningMode}*.xrules
>
> As the rules have a name (unique identifier) it's possible to overwrite
> them inside the running mode specific configuration files.
>
> The rules itself have include directives that can include spring bean
> files from any available path (classpath etc.)
>
> WDYT?
To be honest, I'm a bit confused about what you are proposing.
Without a concrete example and explanation what this rule language is/looks like and is supposed to do my gut reaction is this might be overkill for what we need.
I definitely think we need as simple as possible solution using conventions and a language commonly known.
That's why I tried to come up with a jstl/el type of example as its a standard and widly known language and the runtime evaluation should be easily embeddable.
Defining or even dynamically loading our own custom language seems a bit too far fetched.
But maybe I simply misunderstood your proposal and is it actually very simple, so it would be great if you could provide an example.
Regards, Ate
>
> Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [RT] Spring Configuation
Posted by Carsten Ziegeler <cz...@apache.org>.
Okay, it seems that noone else has done these things already. At least I
haven't found/seen any other examples.
As a starting point I would like to extend the Cocoon Spring
configurator (CSC) with the below described logic. The CSC does already
half of the required stuff (property and overwrite handling), so I think
it makes sense to add the missing piece.
As I already said, the CSC is hosted at Cocoon because this is the place
where it all started. We can move it to whereever we think it needs to
be *and* we can replace the search directory path "cocoon/something"
with something more general.
I hope everyone is fine with this for now?
Ok, currently the CSC reads properties from
META-INF/cocoon/properties and META-INF/cocoon/properties/{runningMode}
The CSC reads spring bean definitions from
META-INF/cocoon/spring/*.xml and META-INF/cocoon/spring/{runningMode}*.xml
It also reads overwrite definitions from
META-INF/cocoon/spring/*.properties and
META-INF/cocoon/spring/{runningMode}*.properties
I propose to add the following:
We define a rule based language - we can either use existing rules
implementations or create our own (xml) based one.
The basic idea is to start with named rules that can test properties and
include bean definitions.
I would start with a simple xml based config file for these rules. The
CSC reads the rules from
META-INF/cocoon/spring/*.xrules and
META-INF/cocoon/spring/{runningMode}*.xrules
As the rules have a name (unique identifier) it's possible to overwrite
them inside the running mode specific configuration files.
The rules itself have include directives that can include spring bean
files from any available path (classpath etc.)
WDYT?
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
Re: [RT] Spring Configuation
Posted by David Jencks <da...@yahoo.com>.
On Dec 11, 2007, at 1:05 AM, 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>
>
> But even in this case, it would be a little bit tricky.
>
> Now, to my knowledge we have two solutions:
> a) we define our own xml parser for these configuration files and this
> parser filters the bean definition, so something like
>
> <bean name="general-db-service".../>
> <cond:if test="o.a.jetspeed.db = hqsldb">
> <bean name="...."/>
> <bean name="...."/>
> </cond>
> <cond:if test="o.a.jetspeed.db = derby">
> <bean name="...."/>
> </cond>
>
> would be possible.
>
> b) We keep the various definitions in separate files, so in this
> example
> we have three configuration files, one containing the general
> definition
> for "general-db-service", one containing the hqsldb variant and one
> for
> the derby stuff.
Why do we need the general-db-service?
> Then we need some external mechanism to specify when to read which
> configuration files.
>
> In both cases we need something like the current cocoon spring
> configurator that controls the parsing of the configuration files. I
> think a) is more maintainable and flexible.
>
> WDYT?
I'm a bit biased since in geronimo we have a system more like (b)
(although we also have (a)). I think separate files together with a
list of files to run will be much more convenient in the long term.
How are you planning to deal with configurations that need classes
that don't come with jetspeed, i.e. extensible classloading?
thanks
david jencks
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [RT] Spring Configuation
Posted by Carsten Ziegeler <cz...@apache.org>.
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>
But even in this case, it would be a little bit tricky.
Now, to my knowledge we have two solutions:
a) we define our own xml parser for these configuration files and this
parser filters the bean definition, so something like
<bean name="general-db-service".../>
<cond:if test="o.a.jetspeed.db = hqsldb">
<bean name="...."/>
<bean name="...."/>
</cond>
<cond:if test="o.a.jetspeed.db = derby">
<bean name="...."/>
</cond>
would be possible.
b) We keep the various definitions in separate files, so in this example
we have three configuration files, one containing the general definition
for "general-db-service", one containing the hqsldb variant and one for
the derby stuff.
Then we need some external mechanism to specify when to read which
configuration files.
In both cases we need something like the current cocoon spring
configurator that controls the parsing of the configuration files. I
think a) is more maintainable and flexible.
WDYT?
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
Re: [RT] Spring Configuation
Posted by Ate Douma <at...@douma.nu>.
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 :)
Regards,
Ate
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org