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
