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 runtime.
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. Having
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, separate
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 class
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 skipped
must be calculated at runtime. That's why I want to introduce the idea of filter to the Spring
Configurator.
--
Grzegorz Kossakowski
