I think we should completely stop using tc.properties except for experimental stuff that has no user-facing behavior. There should be one and only one place where configuration happens. Sent from my handheld
-----Original Message----- From: Steven Harris <[EMAIL PROTECTED]> Date: Mon, 20 Aug 2007 12:41:48 To:Geert Bevin <[EMAIL PROTECTED]> Cc:[email protected] Subject: Re: [tc-dev] basic config For me it's about defaults. These aren't bundles that almost anyone would ever touch. Most of this stuff is currently hard coded somewhere in our jar. That said, I think the tc.properties having a list of defaults is temporary until we decide on a better place to put those defaults. On Aug 20, 2007, at 12:16 PM, Geert Bevin wrote: > Hmm, I have a problem still with using tc.properties. In terms of > setting up an application, I think that a user will expect a single > place to setup config modules that are being used. Currently we > only allow them to be included, thus adding something to include > the default ones seems natural. Otherwise, people will have to > juggle with two locations to get a view of which ones are actually > active and which ones not. Additionally, I think it's a mistake to > treat the additional config bundles that do what modules-common did > as 'more important' or 'higher order'. Just my 2c. > > On 20 Aug 2007, at 21:00, Taylor Gautier wrote: > >> Ok. That sounds to me like tc.properties ;-). >> >> However, I have a request. Is it possible to load tc.properties >> from the root classpath? e.g. getResource("/tc.properties") - >> loading them from the TC installation or the command line seems to >> be preventative from using them in a user context, even if that >> user is advanced. >> >> >> >> Steven Harris wrote: >>> I think the point is to have a way or place to have "default" >>> modules. We could of course hard code those but that is >>> inflexible so we are looking to add some sort of hook where we >>> can have these defaults but make them adjustable for the super >>> advanced user. >>> Cheers, >>> Steve >>> >>> On Aug 20, 2007, at 11:42 AM, Taylor Gautier wrote: >>> >>>> Hi Eugene - >>>> >>>> Then I think we are not agreeing on what the use case is for >>>> refactoring these bundles out and the reason for why a developer >>>> would need to change these settings. >>>> >>>> Generally speaking, tc.properties is a very poor way for >>>> developers to configure Terracotta to work with their their >>>> application. They are generally undocumented, and they are >>>> global to the tc installation, unless they are passed on the >>>> command line, which means that either way, they are environment >>>> specfic, and not included as part of the application. If the >>>> application depends on them to function correctly, then it has a >>>> dependency on the environment settings which is very difficult >>>> to manage through the software development lifecycle. For >>>> these reasons, the tc-config provides a much better environment >>>> for user facing settings. >>>> >>>> So I need to understand why would a developer need to change >>>> these settings? Are they intended to be for a developer to >>>> tweak his/her application so that it runs correctly? If that is >>>> the case then control of these settings should be in tc-config, >>>> not in tc.properties. >>>> >>>> Eugene Kuleshov wrote: >>>>> Taylor, config should probably don't include any implicit >>>>> modules we want to load by default. however using properties we >>>>> can allow user to tweak those implicit modules Taylor Gautier >>>>> wrote: >>>>>> Ok. Well we should do these things in the config. Properties >>>>>> are not user facing and these sound user facing to me. Juris >>>>>> Galang wrote: >>>>>>> I meant properties. On Aug 20, 2007, at 10:14 AM, Taylor >>>>>>> Gautier wrote: >>>>>>>> I suppose you meant a basic set of config settings - not >>>>>>>> properties. Juris Galang wrote: >>>>>>>>> Hi All, We opened a new issue: CDV-384 [ https:// >>>>>>>>> jira.terracotta.org/jira//browse/CDV-384?page=all ] In >>>>>>>>> summary: The idea is that we will have a set of basic >>>>>>>>> config-bundles that will always get installed and started >>>>>>>>> on the L1 The primary intent being, since there are certain >>>>>>>>> configurations that should always be defined when >>>>>>>>> clustering with Terracotta (eg: obfuscated classes will >>>>>>>>> always have to be excluded, certain Java classes that >>>>>>>>> require local resources, Swing components, etc) these >>>>>>>>> config-bundles will take care of it for the user behind-the- >>>>>>>>> scenes. A secondary is goal here is to finally migrate most >>>>>>>>> (if not all) of the default configurations out of the main >>>>>>>>> Terracotta source tree and into the config-bundles. Current >>>>>>>>> thinking is: - To create a set of config-bundles (as >>>>>>>>> opposed to dumping everything in the modules-common bundle) >>>>>>>>> delineated by class, package, framework, or functional >>>>>>>>> concerns; Or whatever makes more sense, like maybe an: >>>>>>>>> always-exclude config-bundle, always-include config-bundle, >>>>>>>>> basic-server-setting config-bundle, basic-logging config- >>>>>>>>> bundle, etc. - To provide a set of Terracotta system >>>>>>>>> properties to tweak which of the basic config-bundles will >>>>>>>>> be installed or started. Default setting would always ALL - >>>>>>>>> To always include these config-bundles in the kit. It would >>>>>>>>> be nice to hear from anyone/everyone interested in shaping >>>>>>>>> how we implement this feature. Thanks. Juris >>>>>>>>> _______________________________________________ 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 >>>> _______________________________________________ >>>> 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 _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
