portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [RT] Spring Configuation
Date Tue, 11 Dec 2007 17:22:24 GMT

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


Mime
View raw message