Re: [RT] Spring Configuation

[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

[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

[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

[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