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
