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] <mailto:[email protected]>
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
