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
