The configuration filename must be specified with the bitronix.tm.configuration system property.
The default settings are good enough for running in a test environment but certainly not for production usage. Also, all properties are reset to their default value after the transaction manager has shut down.
All those properties can refer to other defined ones or to system properties using the Ant notation: ${some.property.name}.
Contains all the variable parameters of a Configurable object.
@author Bryan TrippAs well as holding configuration settings, this class acts as a factory for classes providing service in particular areas: error handling, URI resolution, and the like. Some of these services are chosen on the basis of the current platform (Java or .NET), some vary depending whether the environment is schema-aware or not.
The Configuration provides access to a {@link NamePool} which is used to manageall the names used in stylesheets, queries, schemas, and source and documents: the NamePool allocates integer codes to these names allowing efficient storage and comparison. Normally there will be a one-to-one relationship between a NamePool and a Configuration. It is possible, however, for several Configuration objects to share the same NamePool. Until Saxon 8.9, by default all Configuration objects shared a single NamePool unless configured otherwise; this changed in 8.9 so that the default is to allocate a new NamePool for each Configuration.
The Configuration establishes the scope within which node identity is managed. Every document belongs to a Configuration, and every node has a distinct identity within that Configuration. In consequence, it is not possible for any query or transformation to manipulate multiple documents unless they all belong to the same Configuration.
Since Saxon 8.4, the JavaDoc documentation for Saxon attempts to identify interfaces that are considered stable, and will only be changed in a backwards-incompatible way if there is an overriding reason to do so. These interfaces and methods are labelled with the JavaDoc "since" tag. The value 8.n indicates a method in this category that was introduced in Saxon version 8.n: or in the case of 8.4, that was present in Saxon 8.4 and possibly in earlier releases. (In some cases, these methods have been unchanged for a long time.) Methods without a "since" tag, although public, are provided for internal use or for use by advanced users, and are subject to change from one release to the next. The presence of a "since" tag on a class or interface indicates that there are one or more methods in the class that are considered stable; it does not mean that all methods are stable. @since 8.4
Configuration bean.
@author Zhang, Zheng @version 2.0
@author unknown
@author Marc Guillemot
@author Paul King
@webtest.step category="General"name="config" description="This is a nested task of
For example, given the following configuration file:
members: - Hollie - Jason - Bobo - Aya - Tetsu worldguard: fire: spread: false blocks: [cloth, rock, glass] sturmeh: cool: false eats: babies: true
Calling code could access sturmeh's baby eating state by using getBoolean("sturmeh.eats.babies", false). For lists, there are methods such as getStringList that will return a type safe list.
This class is currently incomplete. It is not yet possible to get a node.
This class holds the Dandelion configuration initialized at server startup and must be accessed through the Dandelion {@link Context}.
All configuration present in the {@link DandelionConfig} enum are read usinga particular strategy. See {@link #readConfig(DandelionConfig)}.
There should be only one instance of this class in the application. @author Thibault Duchateau @since 0.10.0
Configuration parameters used to determine locations of files, sizes of buffer pool and journal allocation, policies and other parameters required during Persistit initialization.
An application can construct and set up a Configuration using setXXX methods directly. Alternatively, the configuration can be specified in a set of properties that are read and interpreted by the Configuration. This object is used directly or indirectly by the following methods:
Configuration directly.Configuration from the supplied Properties.Configuration from the loaded Properties. Configuration from the loaded Properties. When parsing Properties values this class implements a simple substitution mechanism so that, for example, a common directory path may be referenced by multiple properties as shown here: datapath = /var/lib/persistit journalpath = ${datapath}/akiban_journal volume.1=${datapath}/hwdemo,create,pageSize:16K,\ initialSize:10M,extensionSize:10M,maximumSize:1G datapath has no special meaning other than as a substitution parameter.
For example, given the following configuration file:
members: - Hollie - Jason - Bobo - Aya - Tetsu worldguard: fire: spread: false blocks: [cloth, rock, glass] sturmeh: cool: false eats: babies: true
Calling code could access sturmeh's baby eating state by using getBoolean("sturmeh.eats.babies", false). For lists, there are methods such as getStringList that will return a type safe list.
This class is currently incomplete. It is not yet possible to get a node.
This is NOT part of any supported API. If you write code that depends on this, you do so at your own risk. This code and its internal interfaces are subject to change or deletion without notice. @author Robert Field. @author Atul Dambalkar. @author Jamie Ho
Description: The configuration object of the logging, use {@link WriterConfig} to define the {@link com.toc.logging.writer.Writer Writer} of logging in a map and indicate the status of the logging.
Copyright: Copyright (c) 2009 Thousand Origami Cranes Corp.
Create Time: 25 Dec 2009 10:01:49 @author Kevin.Zhou @version 1.0 @see com.toc.logging.config.WriterConfig @see com.toc.logging.Log
Configuration interface allows clients to set compiler options for Application and Library. The client can not instantiate a Configuration object. It can be obtained by invoking the getDefaultConfiguration() method in Application and Library. Application app = new Application(new File("HelloWorld.mxml")); Configuration c1 = app.getDefaultConfiguration(); Library lib = new Library(); Configuration c2 = lib.getDefaultConfiguration(); The compiler populates the default Configuration object with the values in flex-config.xml. If a local configuration file is also available (for example, HelloWorld-config.xml), the compiler also uses values in that file to populate the Configuration object. The local configuration file's values take precedence over options set in the flex-config.xml file. If you add a configuration file using the addConfiguration() method, that configuration file's options take precedence over those set in flex-config.xml or in a local configuration file; they do not take precedence over configuration options set using the Configuration interface's methods such as setExterns(). The order of configuration option precedence is as follows (highest first):
1. Methods of the@version 2.0.1 @author Clement WongConfigurationinterface such assetExterns(). 2. Configuration file loaded with theaddConfiguration()method. 3. Local configuration file (such as app_name-config.xml). 4. The flex-config.xml file. 5. Default compiler settings.
Configuration object, and don't change the settings anymore.
@author Jonathan Revusky
@author Attila Szegedi
@version $Id: Configuration.java,v 1.122.2.5 2006/04/26 21:25:19 ddekany Exp $
A login configuration contains the following information. Note that this example only represents the default syntax for the {@code Configuration}. Subclass implementations of this class may implement alternative syntaxes and may retrieve the {@code Configuration} from any source such as files, databases,or servers.
Name { ModuleClass Flag ModuleOptions; ModuleClass Flag ModuleOptions; ModuleClass Flag ModuleOptions; }; Name { ModuleClass Flag ModuleOptions; ModuleClass Flag ModuleOptions; }; other { ModuleClass Flag ModuleOptions; ModuleClass Flag ModuleOptions; }; Each entry in the {@code Configuration} is indexed via anapplication name, Name, and contains a list of LoginModules configured for that application. Each {@code LoginModule}is specified via its fully qualified class name. Authentication proceeds down the module list in the exact order specified. If an application does not have a specific entry, it defaults to the specific entry for "other".
The Flag value controls the overall behavior as authentication proceeds down the stack. The following represents a description of the valid values for Flag and their respective semantics:
1) Required - The {@code LoginModule} is required to succeed.If it succeeds or fails, authentication still continues to proceed down the {@code LoginModule} list.2) Requisite - The {@code LoginModule} is required to succeed.If it succeeds, authentication continues down the {@code LoginModule} list. If it fails,control immediately returns to the application (authentication does not proceed down the {@code LoginModule} list).3) Sufficient - The {@code LoginModule} is not required tosucceed. If it does succeed, control immediately returns to the application (authentication does not proceed down the {@code LoginModule} list).If it fails, authentication continues down the {@code LoginModule} list.4) Optional - The {@code LoginModule} is not required tosucceed. If it succeeds or fails, authentication still continues to proceed down the {@code LoginModule} list. The overall authentication succeeds only if all Required and Requisite LoginModules succeed. If a Sufficient {@code LoginModule} is configured and succeeds,then only the Required and Requisite LoginModules prior to that Sufficient {@code LoginModule} need to have succeeded forthe overall authentication to succeed. If no Required or Requisite LoginModules are configured for an application, then at least one Sufficient or Optional {@code LoginModule} must succeed.
ModuleOptions is a space separated list of {@code LoginModule}-specific values which are passed directly to the underlying LoginModules. Options are defined by the {@code LoginModule} itself, and control the behavior within it.For example, a {@code LoginModule} may define options to supportdebugging/testing capabilities. The correct way to specify options in the {@code Configuration} is by using the following key-value pairing:debug="true". The key and value should be separated by an 'equals' symbol, and the value should be surrounded by double quotes. If a String in the form, ${system.property}, occurs in the value, it will be expanded to the value of the system property. Note that there is no limit to the number of options a {@code LoginModule} may define.
The following represents an example {@code Configuration} entrybased on the syntax above:
Login { com.sun.security.auth.module.UnixLoginModule required; com.sun.security.auth.module.Krb5LoginModule optional useTicketCache="true" ticketCache="${user.home}${/}tickets"; }; This {@code Configuration} specifies that an application named,"Login", requires users to first authenticate to the com.sun.security.auth.module.UnixLoginModule, which is required to succeed. Even if the UnixLoginModule authentication fails, the com.sun.security.auth.module.Krb5LoginModule still gets invoked. This helps hide the source of failure. Since the Krb5LoginModule is Optional, the overall authentication succeeds only if the UnixLoginModule (Required) succeeds.
Also note that the LoginModule-specific options, useTicketCache="true" and ticketCache=${user.home}${/}tickets", are passed to the Krb5LoginModule. These options instruct the Krb5LoginModule to use the ticket cache at the specified location. The system properties, user.home and / (file.separator), are expanded to their respective values.
There is only one Configuration object installed in the runtime at any given time. A Configuration object can be installed by calling the {@code setConfiguration} method. The installed Configuration objectcan be obtained by calling the {@code getConfiguration} method.
If no Configuration object has been installed in the runtime, a call to {@code getConfiguration} installs an instance of the defaultConfiguration implementation (a default subclass implementation of this abstract class). The default Configuration implementation can be changed by setting the value of the {@code login.configuration.provider} security property to the fullyqualified name of the desired Configuration subclass implementation.
Application code can directly subclass Configuration to provide a custom implementation. In addition, an instance of a Configuration object can be constructed by invoking one of the {@code getInstance} factory methodswith a standard type. The default policy type is "JavaLoginConfig". See the Configuration section in the Java Cryptography Architecture Standard Algorithm Name Documentation for a list of standard Configuration types. @see javax.security.auth.login.LoginContext @see java.security.Security security properties
Configuration methods. The {@link ValidationProviderResolver} is specified at configuration time(see {@link javax.validation.spi.ValidationProvider}). If none is explicitly requested, the default ValidationProviderResolver is used. The provider is selected in the following way: Validation.byProvider(Class), find the first provider implementing the provider class requested and use itValidationProviderResolverA configuration state may be used to retrieve configuration information about of the associated JAX-RS context (e.g. application, resource method, etc.) or component (e.g. {@link javax.ws.rs.client.Client}, {@link javax.ws.rs.client.WebTarget}, etc.). Configuration information consists of properties, registered JAX-RS component classes and/or instances.
@author Marek Potociar @since 2.0 Configuration config = new Configuration().load(); ActionFactory factory = config.getFactory(); factory...
component and a name. Methods that retrieve entries can specify a default value to return in case the entry is not found, and supply data to use when computing the value of the entry. Application developers are encouraged to use this interface, rather than explicitly constructing instances of exporters and proxy preparers, so that applications can be customized without requiring code modifications. Applications should normally use {@link ConfigurationProvider} to obtain Configuration instances,rather than referencing implementation classes directly, so that the interpretation of configuration options can be customized without requiring code modifications.
@author Sun Microsystems, Inc.
@since 2.0
Attributes are specified for classes of objects: for example, all vertices of type T will have an attribute A which has the value V. Examples of such attributes for vertices are "shape" or "color".
Parameters are specified for each instance of graph/vertex/edge. Examples of parameters are position or id.
@author Matthieu WipliezAs well as holding configuration settings, this class acts as a factory for classes providing service in particular areas: error handling, URI resolution, and the like. Some of these services are chosen on the basis of the current platform (Java or .NET), some vary depending whether the environment is schema-aware or not.
The Configuration provides access to a {@link NamePool} which is used to manageall the names used in stylesheets, queries, schemas, and source and documents: the NamePool allocates integer codes to these names allowing efficient storage and comparison. Normally there will be a one-to-one relationship between a NamePool and a Configuration. It is possible, however, for several Configuration objects to share the same NamePool. Until Saxon 8.9, by default all Configuration objects shared a single NamePool unless configured otherwise; this changed in 8.9 so that the default is to allocate a new NamePool for each Configuration.
The Configuration establishes the scope within which node identity is managed. Every document belongs to a Configuration, and every node has a distinct identity within that Configuration. In consequence, it is not possible for any query or transformation to manipulate multiple documents unless they all belong to the same Configuration.
Saxon-EE has a subclass of the Configuration class which provides the additional services needed for schema-aware processing. The {@link com.saxonica.config.EnterpriseConfiguration}also holds a cache of loaded schema components used for compiling schema-aware transformations and queries, and for validating instance documents.
Since Saxon 8.4, the JavaDoc documentation for Saxon attempts to identify interfaces that are considered stable, and will only be changed in a backwards-incompatible way if there is an overriding reason to do so. These interfaces and methods are labelled with the JavaDoc "since" tag. The value 8.n indicates a method in this category that was introduced in Saxon version 8.n: or in the case of 8.4, that was present in Saxon 8.4 and possibly in earlier releases. (In some cases, these methods have been unchanged for a long time.) Methods without a "since" tag, although public, are provided for internal use or for use by advanced users, and are subject to change from one release to the next. The presence of a "since" tag on a class or interface indicates that there are one or more methods in the class that are considered stable; it does not mean that all methods are stable. @since 8.4
Configuration implements the Singleton Design-Pattern. Up to now, only the Java- Properties can be used as a source for the configuration. Other sources like XML-files or a database are prepared.
Type safe interface for accessing configuration information used to configure Stripes. All Configuration implementations are handed a reference to the BootstrapPropertyResolver to enable them to find initial values and fully initialize themselves. Through the BootstrapPropertyResolver implementations also get access to the ServletConfig of the DispatcherServlet which can be used for locating configuration values if desired.
Implementations of Configuration should fail fast. At initialization time they should detect as many failures as possible and raise an exception. Since exceptions in Configuration are considered fatal there are no exception specifications and implementations are expected to throw runtime exceptions with plenty of details about the failure and its suspected cause(s).
@author Tim FennellIf namespace support is enabled (eg through {@link DefaultConfigurationBuilder#DefaultConfigurationBuilder(boolean) newDefaultConfigurationBuilder(true)}), then the xmlns:doc element will not translate into a Configuration attribute, and the doc:desc element will become a Configuration node with name "desc" and namespace "http://myco.com/documentation". The widget element will have namespace "".
If namespace support is disabled (the default for {@link DefaultConfigurationBuilder}), the above XML will translate directly to Configuration nodes. The my-system node will have an attribute named "xmlns:doc", and a child called "doc:desc".
Assuming the Configuration object is named conf, here is how the data could be retrieved:
| Code | No namespaces | With namespaces |
|---|---|---|
conf. {@link #getName getName}() | my-system | |
conf. {@link #getAttributeNames getAttributeNames}().length | 2 | 1 |
conf. {@link #getChildren getChildren}().length | 2 | |
conf. {@link #getAttributeAsFloat getAttributeAsFloat}("version") | 1.3 | |
conf. {@link #getChild getChild}("widget"). {@link #getAttribute getAttribute}("name") | fooWidget | |
conf. {@link #getChild getChild}("widget") . {@link #getAttributeAsBoolean getAttributeAsBoolean}("threadsafe") | true | |
conf. {@link #getChild getChild}("widget"). {@link #getLocation getLocation}() | file:///home/jeff/tmp/java/avalon/src/java/new.xconf:4:60 | |
conf. {@link #getChild getChild}("desc"). {@link #getName getName}() | desc (see {@link #getChild(String)}) | desc |
conf. {@link #getChild getChild}("doc:desc"). {@link #getName getName}() | doc:desc | doc:desc (see {@link #getChild(String)}) |
conf. {@link #getChild getChild}("desc"). {@link #getValue getValue}() | {@link ConfigurationException} | This is a highly fictitious config file |
conf. {@link #getChild getChild}("doc:desc"). {@link #getValue getValue}() | This is a highly fictitious config file | {@link ConfigurationException} |
conf. {@link #getChild getChild}("desc"). {@link #getNamespace getNamespace}() | http://myco.com/documentation" | |
Type-safe utility methods are provided for retrieving attribute and element values as String, int, long, float and boolean.
Currently, the configuration tree can only be traversed one node at a time, eg., through {@link #getChild getChild("foo")} or {@link #getChildren}. In a future release, it may be possible to access child nodes with an XPath-like syntax.
Checking for the existence of an attribute can be done as follows:
String value = conf.getAttribute( "myAttribute", null ); if ( null == value ) { // Do the processing applicable if the attribute isn't present. }
@author Avalon Development Team
@version CVS $Revision: 1.29 $ $Date: 2004/02/11 14:34:24 $
To use a custom subclass of Configuration, Java applications must call {@link #initializeSharedConfiguration}with the subclass as argument. This will create and initialize a Configuration singleton instance of the specified class. By default {@link DefaultConfiguration}is instantiated.
@author Andrus Adamchik @author Holger HoffstaetteThe main Configuration interface.
This interface allows accessing and manipulating a configuration object. The major part of the methods defined in this interface deals with accessing properties of various data types. There is a generic getProperty() method, which returns the value of the queried property in its raw data type. Other getter methods try to convert this raw data type into a specific data type. If this fails, a ConversionException will be thrown.
For most of the property getter methods an overloaded version exists that allows to specify a default value, which will be returned if the queried property cannot be found in the configuration. The behavior of the methods that do not take a default value in case of a missing property is not defined by this interface and depends on a concrete implementation. E.g. the {@link AbstractConfiguration} class, which is the base class of most configuration implementations provided by this package, per default returns null if a property is not found, but provides the {@link org.apache.commons.configuration.AbstractConfiguration#setThrowExceptionOnMissing(boolean) setThrowExceptionOnMissing()} method, with which it can be configured to throw a NoSuchElementException exception in that case. (Note that getter methods for primitive types in AbstractConfiguration always throw an exception for missing properties because there is no way of overloading the return value.)
With the addProperty() and setProperty() methods new properties can be added to a configuration or the values of properties can be changed. With clearProperty() a property can be removed. Other methods allow to iterate over the contained properties or to create a subset configuration.
The main Configuration interface.
This interface allows accessing and manipulating a configuration object. The major part of the methods defined in this interface deals with accessing properties of various data types. There is a generic {@code getProperty()}method, which returns the value of the queried property in its raw data type. Other getter methods try to convert this raw data type into a specific data type. If this fails, a {@code ConversionException} will be thrown.
For most of the property getter methods an overloaded version exists that allows to specify a default value, which will be returned if the queried property cannot be found in the configuration. The behavior of the methods that do not take a default value in case of a missing property is not defined by this interface and depends on a concrete implementation. E.g. the {@link AbstractConfiguration} class, which is the base classof most configuration implementations provided by this package, per default returns null if a property is not found, but provides the {@link AbstractConfiguration#setThrowExceptionOnMissing(boolean) setThrowExceptionOnMissing()}method, with which it can be configured to throw a {@code NoSuchElementException}exception in that case. (Note that getter methods for primitive types in {@code AbstractConfiguration} always throw an exception for missingproperties because there is no way of overloading the return value.)
With the {@code addProperty()} and {@code setProperty()} methodsnew properties can be added to a configuration or the values of properties can be changed. With {@code clearProperty()} a property can be removed.Other methods allow to iterate over the contained properties or to create a subset configuration.
@author Commons Configuration team @version $Id: Configuration.java 1624601 2014-09-12 18:04:36Z oheger $The Extended Properties syntax is explained here:
key = value Here is an example of a valid extended properties file:
# lines starting with # are comments # This is the simplest property key = value # A long property may be separated on multiple lines longvalue = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa # This is a property with many tokens tokens_on_a_line = first token, second token # This sequence generates exactly the same result tokens_on_multiple_lines = first token tokens_on_multiple_lines = second token # commas may be escaped in tokens commas.excaped = Hi\, what'up?
NOTE: this class has not been written for performance nor low memory usage. In fact, it's way slower than it could be and generates too much memory garbage. But since performance is not an issue during intialization (and there is not much time to improve it), I wrote it this way. If you don't like it, go ahead and tune it up! @author Stefano Mazzocchi @author Jon S. Stevens @author Dave Bryson @author Jason van Zyl @author Geir Magnusson Jr. @author Leon Messerschmidt @author org.apache.flink.configuration.Configuration
Each resources is named by either a String or by a File. If named by a String, then the classpath is examined for a file with that name. If a File, then the filesystem is examined directly, without referring to the CLASSPATH.
Configuration resources are of two types: default and final. Default values are loaded first and final values are loaded last, and thus override default values.
Hadoop's default resource is the String "hadoop-default.xml" and its final resource is the String "hadoop-site.xml". Other tools built on Hadoop may specify additional resources.
Configuration class and its default implementation, ConfigurationImpl, are remnant configuration classes for the UIX portions of Trinidad, and should not be used for new code. @see org.apache.myfaces.trinidadinternal.share.config.ConfigurationImpl @version $Name: $ ($Revision: adfrt/faces/adf-faces-impl/src/main/java/oracle/adfinternal/view/faces/share/config/Configuration.java#0 $) $Date: 10-nov-2005.19:00:18 $ @author The Oracle ADF Faces Team
Configuration interface defines lookup-methods to lookup typed configuration-values. For example boolean getBoolean(String key, boolean defaultValue) looks up a boolean value associated with key. If no value is found for key the boolean defaultValue is returned.
@author Thomas Mahler
@version $Id: Configuration.java,v 1.5.2.1 2005/12/21 22:28:15 tomdz Exp $
The Extended Properties syntax is explained here:
key = value Here is an example of a valid extended properties file:
# lines starting with # are comments # This is the simplest property key = value # A long property may be separated on multiple lines longvalue = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa # This is a property with many tokens tokens_on_a_line = first token, second token # This sequence generates exactly the same result tokens_on_multiple_lines = first token tokens_on_multiple_lines = second token # commas may be escaped in tokens commas.excaped = Hi\, what'up?
NOTE: this class has not been written for performance nor low memory usage. In fact, it's way slower than it could be and generates too much memory garbage. But since performance is not an issue during intialization (and there is not much time to improve it), I wrote it this way. If you don't like it, go ahead and tune it up! @author Stefano Mazzocchi @author Jon S. Stevens @author Dave Bryson @author Jason van Zyl @author Geir Magnusson Jr. @author Leon Messerschmidt @version $Id: Configuration.java,v 1.23 2001/04/09 22:38:39 dlr Exp $
For example, given the following configuration file:
members: - Hollie - Jason - Bobo - Aya - Tetsu worldguard: fire: spread: false blocks: [cloth, rock, glass] sturmeh: cool: false eats: babies: true
Calling code could access sturmeh's baby eating state by using getBoolean("sturmeh.eats.babies", false). For lists, there are methods such as getStringList that will return a type safe list.
This class is currently incomplete. It is not yet possible to get a node.
This class should only be used to hold immutable objects. If you place a mutable object in the configuration and using the subset() method, both configurations will reference the same object and any changes to that object will be reflected in both!
Instances of this class are immutable. @author Adrian Kuhn
SemanticComponent. A Configuration may actually form a tree-shaped structure in order to hold complex configuration data. Each node in the tree is represented by a Configuration object that has a name and may contain attributes, children and text.
The configuration file is loaded from the Java lib directory, the classpath and the Castor JAR. Properties set in the classpath file takes precedence over properties set in the Java library configuration file and properties set in the Castor JAR, allowing for each customization. All three files are named castor.properties.
For example, to change the parser in use, specify that all documents should be printed with identantion or turn debugging on, create a new configuration file in the current directory, instead of modifying the global one. @author Keith Visco @author Assaf Arkin @version $Revision: 1.7 $ $Date: 2004/11/05 05:41:13 $
历史更新记录: 2005-07-16 创建此类型 2008-11-03 增加静态方法：getConfiguration(),configure()方法 2008-11-03 增加静态代码块，从资源根位置装载fto-jthink.xml配置文件@author wenjian @version 1.0 @since JThink 1.0
Implementations have the following responsibilites:
Configurations have dependencies on one another, that result from teh fact that one schema imports another. Configuration dependencies are transitive. Each configuration should declare all dependencies in the constructor using the {@link #addDependency(Configuration)} method. class MyConfiguration extends Configuration { public MyConfiguration() { super(); addDependency( new FooConfiguration() ); addDependency( new BarConfiguration() ); } ... }
In able for a particular binding to be found during a parse, the configuration must first populate a container with said binding. This can be done by returning the appropriate instance of {@link org.geotools.xml.BindingConfiguration} in {@link #getBindingConfiguration()}:
BindingConfiguration getBindingConfiguration() { return new MyBindingConfiguration(); } Instances of type {@link org.geotools.xml.BindingConfiguration} are used topopulate a container with all the bindings from a particular schema. Many bindings have dependencies on other types of objects. The pattern used to satisfy these dependencies is known as Constructor Injection. Which means that any dependencies a binding has is passed to it in its constructor. For instance, the following binding has a dependency on java.util.List.
class MyBinding implements SimpleBinding { List list; public MyBinding(List list) { this.list = list; } } Before a binding can be created, the container in which it is housed in must be able to satisfy all of its dependencies. It is the responsibility of the configuration to statisfy this criteria. This is known as configuring the binding context. The following is a suitable configuration for the above binding. class MyConfiguration extends Configuration { .... void configureContext(MutablePicoContainer container) { container.registerComponentImplementation(ArrayList.class); } } XML instance documents often contain schema uri references that are invalid with respect to the parser, or non-existant. A configuration can supply specialized look up classes to prevent the parser from following an invalid uri and prevent any errors that may occur as a result.
An instance of {@link org.eclipse.xsd.util.XSDSchemaLocationResolver} can beused to override a schemaLocation referencing another schema. This can be useful when the entity parsing an instance document stores schemas in a location unkown to the entity providing hte instance document.
An instance of {@link org.eclipse.xsd.util.XSDSchemaLocator} can be usedto provide an pre-parsed schema and prevent the parser from parsing a schemaLocation manually. This can be useful when an instance document does not supply a schemaLocation for the targetNamespace of the document.
class MyConfiguration implements Configuration { XSDSchemaLocationResolver getSchemaLocationResolver() { return new MySchemaLocationResolver(); } XSDSchemaLocator getSchemaLocator() { return new MySchemaLocator(); } } The XSDSchemaLocator and XSDSchemaLocationResolver implementations are used in a couple of scenarios. The first is when the schemaLocation attribute of the root element of the instance document is being parsed. The schemaLocation attribute has the form:
schemaLocation="namespace location namespace location ..." In which (namespace,location) tuples are listed. For each each namespace encountered when parsing the schemaLocation attribute, an appropriate resolver / locator is looked up. If an override is not aviable, the framework attempts to resolve the location part of the tuple into a schema. The second scenario occurs when the parsing of a schema encounters an import or an include element. These elements have the form: <import namespace="" schemaLocation=""/> and: <include schemaLocation=""> respectivley. Similar to above, the schemaLocation (and namespace in the case of an import) are used to find an override. If not found they are resolved directly.
@author Justin Deoliveira,Refractions Research Inc.,jdeolive@refractions.net
@see org.geotools.xml.BindingConfiguration
@source $URL$
A {@code Configuration} represents a group of artifacts and their dependencies.
Provides configuration options. @author Adrian Brock @version $Revision: 70886 $
Note that, while during setup, the settings, flags, and other values may be set multiple times. But once the lockSettings() method is invoked, they cannot be changed. The default behavior of the Genotype constructor is to invoke this method, meaning that once a Configuration object is passed to a Genotype, it cannot be subsequently modified. There is no mechanism for unlocking the settings once they are locked.
Not all configuration options are required. See the documentation for each of the respective mutator methods to determine whether it is required to provide a value for that setting, and what the setting will default to if not. @author Neil Rotstan @author Klaus Meffert @since 1.0
Configuration configures a {@link DSLContext}, providing it with information for query construction, rendering and execution. A Configuration wraps all information elements that are needed...
The simplest usage of a Configuration instance is to use it exactly for a single Query execution, disposing it immediately. This will make it very simple to implement thread-safe behaviour.
At the same time, jOOQ does not require Configuration instances to be that short-lived. Thread-safety will then be delegated to component objects, such as the {@link ConnectionProvider}, the {@link ExecuteListener}list, etc.
@author Lukas Eder
jscsi-target.xml.
@author Andreas Ergenzinger, University of Konstanz
This class represents the configuration of Aspirin. You can configure this software two ways:
There is a way to change behavior of Aspirin dynamically. You can use JMX to change configuration parameters. In the parameters list we marked the parameters which are applied immediately. For more information view {@link ConfigurationMBean}.
| Name | Type | Description |
|---|---|---|
| aspirin.delivery.attempt.delay | Integer | The delay of next attempt to delivery in milliseconds. Change by JMX applied immediately. |
| aspirin.delivery.attempt.count | Integer | Maximal number of delivery attempts of an email. Change by JMX applied immediately. |
| aspirin.delivery.bounce-on-failure | Boolean | If true, a bounce email will be send to postmaster on failure. Change by JMX applied immediately. |
| aspirin.delivery.debug | Boolean | If true, full SMTP communication will be logged. Change by JMX applied immediately. |
| aspirin.delivery.expiry | Long | Time of sending expiry in milliseconds. The queue send an email until current time = queueing time + expiry. Default value is -1, it means forever (no expiration time). Change by JMX applied immediately. |
| aspirin.delivery.threads.active.max | Integer | Maximum number of active delivery threads in the pool. Change by JMX applied immediately. |
| aspirin.delivery.threads.idle.max | Integer | Maximum number of idle delivery threads in the pool (the deilvery threads over this limit will be shutdown). Change by JMX applied immediately. |
| aspirin.delivery.timeout | Integer | Socket and {@link Transport} timeout in milliseconds. Change by JMX applied immediately. |
| aspirin.encoding | String | The MIME encoding. Change by JMX applied immediately. |
| aspirin.hostname | String | The hostname. Change by JMX applied immediately. |
| aspirin.logger.name | String | The name of the logger. Change by JMX applied immediately. WARNING! Changing logger name cause replacing of logger. |
| aspirin.logger.prefix | String | The prefix of the logger. This will be put in the logs at the first position. Change by JMX applied immediately. |
| aspirin.postmaster.email | String | The email address of the postmaster. Change by JMX applied immediately. |
| aspirin.mailstore.class | String | The class name of mail store. Default class is SimpleMailStore in org.masukomi.aspirin.core.store package. |
| aspirin.queuestore.class | String | The class name of queue store. Default class is SimpleQueueStore in org.masukomi.aspirin.core.queue package. |
A {@code Configuration} object contains a configuration dictionary and allowsthe properties to be updated via this object. Bundles wishing to receive configuration dictionaries do not need to use this class - they register a {@code ManagedService} or {@code ManagedServiceFactory}. Only administrative bundles, and bundles wishing to update their own configurations need to use this class.
The properties handled in this configuration have case insensitive {@code String} objects as keys. However, case must be preserved from the lastset key/value.
A configuration can be bound to a specific bundle or to a region of bundles using the location. In its simplest form the location is the location of the target bundle that registered a Managed Service or a Managed Service Factory. However, if the location starts with {@code ?} then thelocation indicates multiple delivery. In such a case the configuration must be delivered to all targets. If security is on, the Configuration Permission can be used to restrict the targets that receive updates. The Configuration Admin must only update a target when the configuration location matches the location of the target's bundle or the target bundle has a Configuration Permission with the action {@link ConfigurationPermission#TARGET} and a name that matches theconfiguration location. The name in the permission may contain wildcards ( {@code '*'}) to match the location using the same substring matching rules as {@link Filter}. Bundles can always create, manipulate, and be updated from configurations that have a location that matches their bundle location.
If a configuration's location is {@code null}, it is not yet bound to a location. It will become bound to the location of the first bundle that registers a {@code ManagedService} or {@code ManagedServiceFactory} objectwith the corresponding PID.
The same {@code Configuration} object is used for configuring both a ManagedService Factory and a Managed Service. When it is important to differentiate between these two the term "factory configuration" is used. @noimplement @author $Id: bc83a488c091cf0fbeb90e2c013f637bc82f2a26 $
As well as holding configuration settings, this class acts as a factory for classes providing service in particular areas: error handling, URI resolution, and the like. Some of these services are chosen on the basis of the current platform (Java or .NET), some vary depending whether the environment is schema-aware or not.
The Configuration provides access to a {@link NamePool} which is used to manageall the names used in stylesheets, queries, schemas, and source and documents: the NamePool allocates integer codes to these names allowing efficient storage and comparison. Normally there will be a one-to-one relationship between a NamePool and a Configuration. It is possible, however, for several Configuration objects to share the same NamePool. Until Saxon 8.9, by default all Configuration objects shared a single NamePool unless configured otherwise; this changed in 8.9 so that the default is to allocate a new NamePool for each Configuration.
The Configuration establishes the scope within which node identity is managed. Every document belongs to a Configuration, and every node has a distinct identity within that Configuration. In consequence, it is not possible for any query or transformation to manipulate multiple documents unless they all belong to the same Configuration.
Saxon-SA has a subclass of the Configuration class which provides the additional services needed for schema-aware processing. The {@link com.saxonica.validate.SchemaAwareConfiguration}also holds a cache of loaded schema components used for compiling schema-aware transformations and queries, and for validating instance documents.
Since Saxon 8.4, the JavaDoc documentation for Saxon attempts to identify interfaces that are considered stable, and will only be changed in a backwards-incompatible way if there is an overriding reason to do so. These interfaces and methods are labelled with the JavaDoc "since" tag. The value 8.n indicates a method in this category that was introduced in Saxon version 8.n: or in the case of 8.4, that was present in Saxon 8.4 and possibly in earlier releases. (In some cases, these methods have been unchanged for a long time.) Methods without a "since" tag, although public, are provided for internal use or for use by advanced users, and are subject to change from one release to the next. The presence of a "since" tag on a class or interface indicates that there are one or more methods in the class that are considered stable; it does not mean that all methods are stable. @since 8.4
@This Configuration<MyServiceConfiguration> config;
If a new Configuration instance is created then it will be populated with properties from the properties file whose filesystem name is the same as the identity (e.g. "MyService.properties"). If a service is not given a name via the {@link org.qi4j.bootstrap.ServiceDeclaration#identifiedBy(String)}, the name will default to the FQCN of the ServiceComposite type.
The Configuration instance can be modified externally just like any other EntityComposite, but its values will not be updated in the Service until {@link #refresh()} is called. This allowssafe reloads of Configuration state to ensure that it is not reloaded while the Service is handling a request.
The Configuration will be automatically refreshed when the Service is activated through the {@link org.qi4j.api.service.Activatable#activate()} method by the Qi4j runtime.Any refreshes at other points will have to be done manually or triggered through some other mechanism.
The user configuration entity is part of a long running {@link UnitOfWork}, and to persist changes to it the {@link #save()} method must be called. No other actions are required. Example;
public interface MyConfiguration extends ConfigurationComposite { Property<Long> timeout(); } : @This Configuration<MyConfiguration> config; : private void setTimeoutConfiguration( long timeout ) { config.configuration().timeout().set( timeout ); config.save(); }
it is preferred to use {@link org.reflections.util.ConfigurationBuilder}
A Configuration has one or more named {@link Property} objects contained within it (similar to aMap). Note that {@link Property} is an abstract class that actually represents either:
Because a Configuration can contain a list or map of properties, a Configuration can contain a hierarchy of properties N-levels deep.
Each Property within a Configuration has a name - this not only includes simple properties, but also lists and maps of properties as well. For example, you can retrieve a list of properties via {@link #getList(String)} bypassing in the name of the list.
@author Jason Dobies @author Greg Hinkle @see Property @see PropertySimple @see PropertyList @see PropertyMapGeneral configuration class, containing all the configuration items for a {@link TemplateEngine}, including all the info for every configured {@link IDialect}.
Except for testing purposes, there is no reason why a user might need to use this class directly.
@author Daniel Fernández @since 1.0To retrieve the current configuration, use {@link org.zkoss.zk.ui.WebApp#getConfiguration}.
Note: A {@link Configuration} instance can be assigned to at most one{@link WebApp} instance. @author tomyeh
It must contain, at a minimum, an instance of ModelDirectory, named "directory", and an instance of EffigyFactory, named "effigyFactory". The openModel() method delegates to the effigy factory the opening of a model. It may also contain an instance of TextEditorTableauFactory, named "tableauFactory". A tableau is a visual representation of the model in a top-level window. The above minimal configuration can be used to run Ptolemy II models by opening a run panel only.
When the directory becomes empty (all models have been closed), it removes itself from the configuration. When this happens, the configuration calls System.exit() to exit the application.
To access the configuration from a random place, if you have a NamedObj foo, then you can call:
Effigy effigy = Configuration.findEffigy(foo.toplevel()); Configuration configuration = effigy.toplevel();@author Steve Neuendorffer and Edward A. Lee @version $Id: Configuration.java,v 1.119.4.1 2008/03/26 19:32:54 cxh Exp $ @since Ptolemy II 1.0 @Pt.ProposedRating Green (eal) @Pt.AcceptedRating Yellow (celaine) @see EffigyFactory @see ModelDirectory @see Tableau @see TextEditorTableau
When you add to this class, please add the corresponding entries to hashCode and equals.
This class is using the built-in clone method, hence all attributes have to be either primitives or immutable (such as String).
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |