Cool! This sounds very good to me ... glad that you opened the can of worms Tim :-)
On 25 Sep 2007, at 20:55, Alex Miller wrote: > That all sounds right to me. Maybe we don't need a meeting on this > - just a commitment to make it better in the future. I created a > new JIRA (DEV-969) for this: > > JIRA - https://jira.terracotta.org/jira/browse/DEV-969 > -------------------------------------------------------- > Based on tc-dev thread (started by Geert, commented on by Tim, > Taylor, etc), we should make the definition and use of > tc.properties props more consistent and centralized in the code. > Specifically, we should: > > 1) Move prop definitions into a central source file so we know > where to look > 2) Make key space follow some convention (none followed now) > 3) Minimize or eliminate use of tc.properties by config modules > > Notes from Tim: > - tc.config and tc.install-root should remain as system properties > and should NOT be in tc.properties - they are needed for > bootstrapping and are two widely used > - due to #3 above, the source file we define tc props in should > probably not be in a -api project (unless that's the only option > due to other dependencies) > -------------------------------------------------------- > > and the the issue review board can schedule as desired... > > > > ----- Original Message ----- > From: "Taylor Gautier" <[EMAIL PROTECTED]> > To: [email protected] > Sent: Tuesday, September 25, 2007 1:33:54 PM (GMT-0600) America/ > Chicago > Subject: Re: [tc-dev] TC system properties > > 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 > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
