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
