cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: Spring Configurator - filter/include strategy
Date Tue, 15 Jul 2008 12:58:58 GMT
Hi,

I'm not sure what the best way is - but the jetspeed folks followed a 
different road and added conditionals inside the configuration files.
So only if a criteria is met something is added. I tried to convince 
them to use the spring configurator and add the logic here...
So perhaps this is something we could add on top of the configurator now?

Carsten

Grzegorz Kossakowski wrote:
> Hi Cocooners,
> 
> I would like to implement handling of pluggable include or filtering 
> strategies for properties and beans definitions files in Spring 
> Configurator.
> 
> Even if I strongly believe that usually it's better to stick to the 
> conventions Configurator enforces or use wildcard patterns there are 
> some situations when more sophisticated logic is needed. My use-case is 
> that some Spring beans should be included only if appropriate license 
> file is provided in the classpath. This way one can enable and disable 
> modules depending on what license file provide. This can be generalized 
> to use-case when one wants to include some beans depending on some 
> configuration options.
> 
> The idea is to implement handling of include or filtering strategies 
> that would be just a simple Java classes. For include strategy interface 
> could look like:
> 
> public interface IncludeStrategy {
>     Set include();
> }
> 
> where the set would contain URLs pointing to properties/beans need to be 
> included.
> 
> On the other hand, filter would look like:
> public interface FilterStrategy {
>     Set filter(Set urls);
> }
> 
> so the Spring Configurator would first prepare a set of URLs of 
> resources it wants to include and call the filter to filter them out. 
> Actually, in the second approach there is nothing that enforces 
> filtering behaviour on a class implementing the filter. There would be 
> possibility to add any arbitrary URLs the class implementing the filter 
> like.
> 
> Therefore I'm in favor of implementing the second approach option and 
> initially allow to define only one filter in following way:
> 
> <configurator:settings>
>   <configurator:resource-filter class="org.sth.FilterClass"/>
> </configurator:settings>
> 
> 
> What are your opinions on this idea? I would like to start implementing 
> this tomorrow.
> 
> Of course, this change (bringing some new functionality) will bump 
> version number of both Configurator API and Spring Configurator to 1.1.x.
> 


-- 
Carsten Ziegeler
cziegeler@apache.org

Mime
View raw message