cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Spring Configurator - filter/include strategy
Date Tue, 15 Jul 2008 12:40:06 GMT
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.

-- 
Best regards,
Grzegorz Kossakowski

Mime
View raw message