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
[EMAIL PROTECTED]
