portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [RT] Spring Configuation
Date Tue, 11 Dec 2007 17:39:38 GMT
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 Ziegeler

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message