cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Spring Configurator - filter/include strategy
Date Tue, 15 Jul 2008 14:14:35 GMT
Carsten Ziegeler pisze:
> Fair enough :)
> Now I was very brief as I'm not 100% sure how the final solution in 
> jetspeed looks like.
> Ok, our spring configurator includes all files located at a specific 
> location and adds all bean definitions found there.

Yep, and currently you have no option to filter out something depending on some results from

> The jetspeed guys enhanced the spring bean configuration format to have
> conditionals inside a bean xml definition, so something like (don't 
> quote me on the syntax):
> <j:if test="database.derby">
>   <bean name="database" ...the derby bean
> <j:if>
> <j:else>
>   <bean name="database" ...the hsqldb bean
> </j:else>
> This allows to have all relevant bean definitions at one single place 
> and at runtime it's decided which beans to use.
> So this is somthing "on top of the configurator" as this doesn't effect
> the current configurator code but is just additional stuff.

Yes, agreed but still I cannot help my feeling that such conditionals are simply a bad idea.
everything in one place is a benefit of course but on the other hand I would prefer to use

directories or file name patterns (known from file systems) to distinguish between various,
options. That feels much more natural for me.

Then you would still need to have some conditional processing but that could be a simple Java
that picks up the right resources.

It's maybe a matter of a taste but introduction of any logic to the configuration is wrong.

Configuration should be always declarative not imperative, IMHO.

> But rereading your use case, I assume that you want to skip whole jar 
> files, right? So this would be something in the spring configurator of
> course.

Yes. At least, I need something that will let me to skip some inclusions and what should be
must be calculated at runtime. That's why I want to introduce the idea of filter to the Spring


Grzegorz Kossakowski

View raw message