I agree that making those would simplify a lot, I can make these
changes if everyone (or at least the half plus one) agrees.
--
Bauna
On 12/10/2009 08:32 PM, Edson Tirelli wrote:
Hi Pablo,
Thanks for looking into that. I am not sure why I added the
chained properties in there.. probably a copy&paste from older
classes, but the idea is that the main configuration classes are the
implementations of:
So, any configuration should be an attribute of these classes.
Whatever is not in these classes, should not be considered an actual
configuration. The chained properties class was supposed to be a
read-once utility class to initialize the configuration classes based
on files, sysproperties, etc. So, first thing I would do now would be
to remove the chained properties from the configuration class. That
will simplify everything.
Any configuration option will be explicit, and once the actual
session/base/builder is created, it becomes immutable. No need for
inspecting APIs other than what is provided in the classes. The chained
properties class would still be used just to initialize the values of
the attributes, but would be thrown away after that.
Hi
all,
I'm working on drools spring and I've come upon some issues in
SessionConfiguration that are stopping/confusing me.
Here are my lists of doubts/concerns about SessionConfiguration:
1) It stores 2 properties using Option instances variables and the rest
inside a ChainedProperties class.
2) There is no way no way to know what props are in the
ChainedProperties from outside the SessionConfiguration.
3) When the SessionConfiguration is immutable, it's still possible to
add more Properties using the addProperties method.
4) The ChainedProperties class is add only, in other words it isn't
possible change props values. Moreover it's also possible to have two
props with different values.
I'm attaching a patch that fix some these issues. I've updated
SessionConfiguration (g|s)etProperty(String name) method and added the
ability to ChainedProperties update existing props.