Small fast utility for efficient construction of elements and attributes. Implemented via a LRU cache of the most recent elements and attributes.
Avoids repeated XML reverification in XOM Element and Attribute constructor on cache hit, plus avoids generating new String objects by quasi "interning" localName and prefix, which in turn reduces memory consumption. Has overhead close to zero on cache miss.
This implementation is not thread-safe.
This class would become obsolete if the XOM Element and Attribute classes would have an internal LRU cache of QNames. @author whoschek.AT.lbl.DOT.gov @author $Author: hoschek3 $ @version $Revision: 1.7 $, $Date: 2006/01/02 01:08:51 $
A node builder can be thought of as a mutable version of a node state. In addition to property and child node access methods like the ones that are already present in the NodeState interface, the {@code NodeBuilder}interface contains the following key methods:
NodeBuilder rootBuilder = root.builder(); NodeBuilder fooBuilder = rootBuilder.getChildNode("foo"); NodeBuilder barBuilder = fooBuilder.getChildNode("bar"); assert !barBuilder.getBoolean("x"); fooBuilder.getChildNode("bar").setProperty("x", Boolean.TRUE); assert barBuilder.getBoolean("x"); assert barBuilder.exists(); fooBuilder.removeChildNode("bar"); assert !barBuilder.exists(); The {@code getNodeState} method returns a frozen, immutable snapshot of the currentstate of the builder. Providing such a snapshot can be somewhat expensive especially if there are many changes in the builder, so the method should generally only be used as the last step after all intended changes have been made. Meanwhile the accessors in the {@code NodeBuilder} interface can be used to provide efficient read access tothe current state of the tree being modified. The node states constructed by a builder often retain an internal reference to the base state used by the builder. This allows common node state comparisons to perform really.
Settings will be loaded relative to the ES home (with or without config/ prefix) and if not found, within the classpath (with or without config/ prefix). The settings file loaded can either be named elasticsearch.yml or elasticsearch.json). Loading settings can be disabled by calling {@link #loadConfigSettings(boolean)} with false.
Explicit settings can be passed by using the {@link #settings(Settings)} method.
In any case, settings will be resolved from system properties as well that are either prefixed with es. or elasticsearch..
An example for creating a simple node with optional settings loaded from the classpath:
Node node = NodeBuilder.nodeBuilder().node();
An example for creating a node with explicit settings (in this case, a node in the cluster that does not hold data):
Node node = NodeBuilder.nodeBuilder() .settings(ImmutableSettings.settingsBuilder().put("node.data", false) .node(); When done with the node, make sure you call {@link Node#close()} on it. @author kimchy (shay.banon)
| |
| |
| |
| |
| |
| |