Ok, I can adhere to that. tc.properties would then actually be the
way to list the defaults instead of hardcoding them in java code.
Without seeing it really as an solution that users should come in
contact with.
On 20 Aug 2007, at 21:41, Steven Harris wrote:
> 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
>>
>
--
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
