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
