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
