deltaspike-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r865753 - in /websites/staging/deltaspike/trunk/content: ./ configuration.html
Date Sat, 15 Jun 2013 14:25:27 GMT
Author: buildbot
Date: Sat Jun 15 14:25:27 2013
New Revision: 865753

Log:
Staging update by buildbot for deltaspike

Modified:
    websites/staging/deltaspike/trunk/content/   (props changed)
    websites/staging/deltaspike/trunk/content/configuration.html

Propchange: websites/staging/deltaspike/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sat Jun 15 14:25:27 2013
@@ -1 +1 @@
-1492584
+1493366

Modified: websites/staging/deltaspike/trunk/content/configuration.html
==============================================================================
--- websites/staging/deltaspike/trunk/content/configuration.html (original)
+++ websites/staging/deltaspike/trunk/content/configuration.html Sat Jun 15 14:25:27 2013
@@ -189,6 +189,12 @@ lookup chain is used until a value got f
 <h3 id="handling-of-default-values">handling of default values</h3>
 <p>There is a 2nd variant of all those methods where it is possible to provide a
 default value which gets returned instead of <code>null</code> or if the final
result is an empty String.</p>
+<p><strong>Performance Hint:</strong></p>
+<p>The only <code>ConfigResolver</code> operation which is cached is the
determination of the <code>ConfigSources</code>.
+The various getPropertyValue operations are not cached in the ConfigResolver but might be
cached in
+the ConfigSources. This makes the overall calculation a bit slower, but allows for values
to change
+dynamically if someone likes to e.g. implement a <code>JmxConfigSource</code>
(not yet part of DeltaSpike,
+but easily implementable).</p>
 <h1 id="configsource">ConfigSource</h1>
 <p>A <code>ConfigSource</code> is exactly what it's name says: a source
for configured values.
 The <code>ConfigResolver</code> uses all configured implementations of <code>ConfigSource</code>
to lookup the property in question.</p>
@@ -210,7 +216,9 @@ within the release binaries.</p>
 <p><strong>Note:</strong> Important Hints esp. for custom implementations:
   - The config-source with the highest ordinal gets used first.
   - If a custom implementation should be invoked <em>before</em> the default
implementations, use an ordinal-value &gt; 400
-  - If a custom implementation should be invoked <em>after</em> the default implementations,
use an ordinal-value &lt; 100</p>
+  - If a custom implementation should be invoked <em>after</em> the default implementations,
use an ordinal-value &lt; 100
+  - The <code>ConfigResolver</code> performs no caching. If your custom ConfigSource
operation is expensive, then you might
+    think about introducing some caching.</p>
 <h3 id="reordering-of-the-default-order-of-config-sources">Reordering of the default
order of Config-Sources</h3>
 <p>To change the lookup order, you have to configure the ordinal in the corresponding
config source
 (e.g. to change the config ordinal of the config source for system properties, you have to
set



Mime
View raw message