Tim I think you are on the right track here.
Consistent: good.
External: bad.
tc.properties are a way to contain the inevitable "hidden" settings that
creep into any system. For that reason, they are explicitly not
documented, because documentation would necessarily freeze them and
developers would naturally move away for things that are not quite done
in the sense of being mature and documented features.
So making these things external and published and consumable is not a
good idea, imo. Making them consistent is a good idea, so we "contain
the mess(iness)" so to speak.
Tim Eck wrote:
Apologies up front if I create a giant can of worms here, but left
uncontrolled this kind of stuff usually gets out of control. Note: this
isn't related to decision of where the API goes -- that is a different
topic.
I'm personally not a big fan of proliferating the use of system properties
in the code base (even if they get consolidated to some central class, or
set of constants). We created "tc.properties" specifically to avoid using
raw system properties. Conceptually there isn't a huge difference between
tc.props and regular system properties, it's just a way to introduce one
layer of indirection (useful for testing, isolation, different sourcing
methods, etc).
That said there are at two things that should really remain system
properties (tc.config and tc.install-root). Why? They are required for
bootstrapping the client and are firmly cemented in the wild IMO.
Let me be the first to say that "tc.properties" could use some more
attention. Off the top of my head, these are some things could use some
work:
- The key space for tc.props is completely ad-hoc right now -- Something
akin to a constants interface with safety checks built in could fix that
- I don't think tc.props are well suited for config modules
- The implementation uses a static under the covers
So the question I'm really throwing out there is -- Can we unilaterally
use tc.props in place of system properties?
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:tc-dev-
[EMAIL PROTECTED] On Behalf Of Geert Bevin
Sent: Tuesday, September 25, 2007 7:47 AM
To: [email protected]
Subject: [tc-dev] TC system properties
Hi,
I was just reading through the source code and I noticed that the
system properties that are supported by Terracotta are really
scattered around the code base. Wouldn't it be good to create a
TerracottaProperties interface in the 'common' project that
consolidates all these property names as constants? Is 'common' the
correct project for this? Do all the other DSO projects depend on it?
Thanks,
Geert
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev