The FileHandler can either write to a specified file, or it can write to a rotating set of files.
For a rotating set of files, as each file reaches a given size limit, it is closed, rotated out, and a new file opened. Successively older files are named by adding "0", "1", "2", etc into the base filename.
By default buffering is enabled in the IO libraries but each log record is flushed out when it is complete.
By default the XMLFormatter class is used for formatting.
Configuration: By default each FileHandler is initialized using the following LogManager configuration properties. If properties are not defined (or have invalid values) then the specified default values are used.
A pattern consists of a string that includes the following special components that will be replaced at runtime:
Thus for example a pattern of "%t/java%g.log" with a count of 2 would typically cause log files to be written on Solaris to /var/tmp/java0.log and /var/tmp/java1.log whereas on Windows 95 they would be typically written to C:\TEMP\java0.log and C:\TEMP\java1.log
Generation numbers follow the sequence 0, 1, 2, etc.
Normally the "%u" unique field is set to 0. However, if the FileHandler tries to open the filename and finds the file is currently in use by another process it will increment the unique number field and try again. This will be repeated until FileHandler finds a file name that is not currently in use. If there is a conflict and no "%u" field has been specified, it will be added at the end of the filename after a dot. (This will be after any automatically added generation number.)
Thus if three processes were all trying to log to fred%u.%g.txt then they might end up using fred0.0.txt, fred1.0.txt, fred2.0.txt as the first file in their rotating sequences.
Note that the use of unique ids to avoid conflicts is only guaranteed to work reliably when using a local disk file system. @version 1.36, 04/07/06 @since 1.4
A class that manages persistence of an associated {@link FileBased} object.
Instances of this class can be used to load and save arbitrary objects implementing the {@code FileBased} interface in a convenient way from and tovarious locations. At construction time the {@code FileBased} object tomanage is passed in. Basically, this object is assigned a location from which it is loaded and to which it can be saved. The following possibilities exist to specify such a location:
An instance stores a location. The {@code load()} and {@code save()} methodsthat do not take an argument make use of this internal location. Alternatively, it is also possible to use overloaded variants of {@code load()} and {@code save()} which expect a location. In these cases thelocation specified takes precedence over the internal one; the internal location is not changed.
The actual position of the file to be loaded is determined by a {@link FileLocationStrategy} based on the location information that has beenprovided. By providing a custom location strategy the algorithm for searching files can be adapted. Save operations require more explicit information. They cannot rely on a location strategy because the file to be written may not yet exist. So there may be some differences in the way location information is interpreted by load and save operations. In order to avoid this, the following approach is recommended:
When loading or saving a {@code FileBased} object some additionalfunctionality is performed if the object implements one of the following interfaces:
This class is thread-safe.
@version $Id: FileHandler.java 1606588 2014-06-29 19:45:14Z oheger $ @since 2.0A class that manages persistence of an associated {@link FileBased} object.
Instances of this class can be used to load and save arbitrary objects implementing the {@code FileBased} interface in a convenient way from and tovarious locations. At construction time the {@code FileBased} object tomanage is passed in. Basically, this object is assigned a location from which it is loaded and to which it can be saved. The following possibilities exist to specify such a location:
An instance stores a location. The {@code load()} and {@code save()} methodsthat do not take an argument make use of this internal location. Alternatively, it is also possible to use overloaded variants of {@code load()} and {@code save()} which expect a location. In these cases thelocation specified takes precedence over the internal one; the internal location is not changed.
The actual position of the file to be loaded is determined by a {@link FileLocationStrategy} based on the location information that has beenprovided. By providing a custom location strategy the algorithm for searching files can be adapted. Save operations require more explicit information. They cannot rely on a location strategy because the file to be written may not yet exist. So there may be some differences in the way location information is interpreted by load and save operations. In order to avoid this, the following approach is recommended:
When loading or saving a {@code FileBased} object some additionalfunctionality is performed if the object implements one of the following interfaces:
This class is thread-safe.
@version $Id: FileHandler.java 1624601 2014-09-12 18:04:36Z oheger $ @since 2.0Class responsible for generating all the file I/O required for an instance of JBroFuzz to function correctly.
@author subere@uncon.org @version 2.0 @since 1.2 | |
| |
| |
| |
| |
| |
| |
| |
| |
| |