Provides a {@link net.jini.config.Configuration} interface for obtaining objects needed to configure applications, such as {@link net.jini.export.Exporter} or {@link net.jini.security.ProxyPreparer} instances, or other application-specific objects, from configuration files, databases, or other sources. 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 net.jini.config.ConfigurationProvider} to obtain `Configuration` instances, so that the interpretation of configuration options can be customized without requiring code modifications.

The {@link net.jini.config.ConfigurationException} class is the superclass of all exceptions thrown if a problem occurs when obtaining configuration information. {@link net.jini.config.NoSuchEntryException} is the subclass thrown for a missing configuration entry. {@link net.jini.config.ConfigurationNotFoundException} is the subclass thrown for missing configuration source locations and if default options are requested but not available.

The {@link net.jini.config.ConfigurationFile} class is the standard default configuration provider, which reads text written in a subset of the expression syntax in the Java(TM) programming language from files and URLs to produce configuration objects.

The {@link net.jini.config.AbstractConfiguration} class is a skeletal implementation of the `Configuration` interface, used to simplify writing implementations.

The {@link net.jini.config.EmptyConfiguration} class implements a `Configuration` with no entries. Applications can use an instance of this class to simplify handling cases where no configuration is specified rather than, for example, checking for a `null` configuration.

The net.jini.config.GroovyConfig class is a new configuration provider, it uses Groovy configuration objects, this is potentially the most powerful configuration mechanism.

## Using Configuration

Once an application gets a `Configuration` using `ConfigurationProvider` or through an application-specific mechanism, the application should pass that configuration to other subsystems that need configuration information, in addition to using it for its own needs. This arrangement provides the user with a uniform way to supply configuration information to all the components that make up an application.

The names that applications and subsystems use for configuration entries should be chosen carefully to avoid conflicts. One possible approach is to use fully qualified class names as the component for configurable applications and utilities, and to use fully qualified package names as the component for services. For each entry, the decision should be made whether to supply a default or to throw `NoSuchEntryException` if there is no matching entry. Components should document which configuration entries they use, as well as the expected type and default, if any, for each entry.

## Example

Here is a sketch of how to use these facilities for an application with configurable exporting. The class below shows exporting an object using a `Configuration`:

        import java.rmi.*;
        import net.jini.config.*;
        import net.jini.export.*;
        public class Example implements Remote {
            public static void main(String[] args) throws Exception {
                Configuration config = ConfigurationProvider.getInstance(args);
                Exporter exporter = (Exporter) config.getEntry(
                    "Example", "exporter", Exporter.class);
                Remote proxy = exporter.export(new Example());
                System.out.println(proxy);
                exporter.unexport(true);
            }
        }

Here are the contents of a `ConfigurationFile` source file to export the object using an JRMP exporter:

        import net.jini.jrmp.*;
        Example {
            exporter = new JrmpExporter();
        }

Here are the contents of another `ConfigurationFile` to export the object using a Jini extensible remote invocation (Jini ERI) exporter over HTTP on a specific port:

        import net.jini.jeri.*;
        import net.jini.jeri.http.*;
        Example {
            exporter = new BasicJeriExporter(HttpServerEndpoint.getInstance(12000));
        }

This application can be configured to export the object in either of these ways (or more with other configuration files) by passing an argument that specifies the location of one of the configuration files:

        java Example jrmp.config

        java Example jeri.config

@since 2.0 @version 2.0 @org.apache.river.impl

Loggers and Logging Levels

This implementation of the `ConfigurationProvider`, `AbstractConfiguration`, `ConfigurationFile`, and `EmptyConfiguration` classes uses the {@link java.util.logging.Logger} named `net.jini.config` to log information at the following logging levels:

`net.jini.config`
Level | Description
--- | ---
{@link java.util.logging.Level#INFO INFO} | problems adding new prohibited methods for `ConfigurationFile`
{@link org.apache.river.logging.Levels#FAILED FAILED} | problems getting a configuration using `ConfigurationProvider`, or problems getting entries, including getting entries that are not found, from the configuration implementation classes
{@link java.util.logging.Level#FINE FINE} | returning default values from the configuration implementation classes
{@link java.util.logging.Level#FINER FINER} | getting existing entries from the configuration implementation classes, creating a `ConfigurationFile`, or adding new prohibited methods for `ConfigurationFile`

See the {@link org.apache.river.logging.LogManager} class for one way to use the `FAILED` logging level in standard logging configuration files.