Listener interface for the asynchronous filling method.
Context information related to a fill time dataset.
Generic delayed evaluation action.
A fill context provides access to data and functionality related to a report component fill.
Interface implemented by classes that are used to perform report filling asychronously.
Listener notified of page events during a report generation.
Interface for objects that can be used by extended incrementers for calculations.
Extended incrementer interface.
Extended incrementer factory interface.
Interface of elements that can be cloned at fill time.
Fill time expression evaluators interface.
Text measuring information as produced by a
A provider of
Interface implemented by print elements that can record field/variable values.
Subreport runner interface.
Text measurer interface.
Listener that plugs into the virtualization process.
Class used to instantiate sub datasets.
Class used to perform report filling asychronously.
Base class used to perform report filling asychronously.
Delayed evaluation action that evaluates a print element.
Position that uniquely identifies a dataset instantiation as part of a fill process.
Base class for extended incrementers.
Base abstract implementation of
Abstract base for LRU and serialization based virtualizer
Evaluates JasperReports expressions.
Working clones pooling utility used at fill time.
An evaluation time during the report fill process.
Base class for the dynamically generated expression evaluator classes.
Virtualizes data to the filesystem.
Crosstab cell contents filler.
Factory class used for fill-time working clones creation.
Context class shared by all the fillers involved in a report (master and subfillers).
Fill-time implementation of a
Class used to hold expression calculation requirements.
Class used to instantiate sub datasets.
Abstract implementation of an element container filler.
Fill time implementation of a frame element.
Utility class used to evaluate custom hyperlink parameters.
A factory used to instantiate fill objects based on compiled report objects.
GZips the pages that it doesn't need, but keeps them in memory.
Utility class to be used to evaluate parameter default value expressions for a report without actually filling it.
Recorded values container used by elements with
Generic print element implementation that supports recorded values.
Print image implementation that supports recorded values.
Print text implementation that supports recorded values.
Resources utility class used for report fills.
Abstract base for
A virtualizer that uses a single swap file to serialize virtual data.
Base class consisting of print element information shared by multiple print elements.
Ellipse information shared by multiple print ellipse objects.
Frame information shared by multiple print frame objects.
Generic print element information shared by multiple elements.
Base class consisting of graphic print element information shared by multiple print element instances.
Image information shared by multiple print image objects.
Line element information shared by multiple print line objects.
Rectangle information shared by multiple print rectangle objects.
Text element information shared by multiple print text objects.
Context used to store data shared by virtualized objects resulted from a report fill process.
Default text measurer implementation.
Default text measurer factory.
Delayed evaluation action that devirtualizes a set of elements in order to evaluate one or several of them.
The following things should be supplied to the report-filling process as input:
JasperPrintdocument ready to be viewed, printed, or exported to other formats.
JasperFillManager class is usually used for
filling a report template with data. This class has various methods that fill report
templates located on disk, come from input streams, or are supplied directly as in-memory
JasperReport objects. After getting the report template,
the report filling methods are calling the related
fill(...) method in the
JRFiller class, that actually fills the report.
The output produced always corresponds to the type of input received. That is, when receiving a file name for the report template, the generated report is also placed in a file on disk. When the report template is read from an input stream, the generated report is written to an output stream, and so forth.
The various utility methods for filling the reports may not be sufficient for a particular application - for example, loading report templates as resources from the classpath and outputting the generated documents to files on disk at a certain location.
In such cases, manually loading the report template objects is to be considered before passing them
to the report-filling routines using the
JRLoader utility class. This way, one can
retrieve report template properties, such as the report name, to construct the name of the
resulting document and place it at the desired disk location.
The report-filling manager class covers only the most common scenarios. However, you can always customize the report-filling process using the library's basic functionality just described.
JasperPrintobjects, which are serializable. This allows the parent application to store them or transfer them over the network if needed.
At the top level, a
JasperPrint object contains some document-specific information,
like the name of the document, the page size, and its orientation (portrait or landscape).
Then it points to a collection of page objects
JRPrintPage instances), each page having a
collection of elements that make up its content. Elements on a page are absolutely
positioned at x and y coordinates within that page and have a specified width and height
in pixels. They can be lines, rectangles, ellipses, images, or text, with various style
settings corresponding to their type.
When multiple-column report templates are used, the order used for filling those
columns is important.
There are two possible column orders, that can be set in the report template using
Vertical- meaning that they run from top to bottom and then from left to right. This is the default order. The report filling process is provided by the
Horizontal- meaning that they first run from left to right and then from top to bottom. In this case the report is filled using methods in the
AsynchronousFillHandleclass to be used for asynchronous report filling. The main benefit of this method is that the filling process can be canceled if it takes too much time. This can be useful, for example, in GUI applications where the user would be able to abort the filling after some time has elapsed and no result has been yet produced.
When using this method, the filling is started on a new thread. The caller is notified
about the progress of the filling process by way of listeners implementing the
AsynchronousFilllListener interface. The
listeners are notified of the outcome of the filling process, which can be success, failure,
or user cancellation. The handle is used to start the filling process, register listeners, and
cancel the process if wanted.
A typical usage of this handle is the following:
AsynchronousFillHandlethat take as arguments the report object, the parameter map, and the data source or the database connection to be used.
addListener()method. In a GUI application, the listener could perform some actions to present to the user the outcome of the filling process.
startFill()method. In a GUI application, this could be the result of some user action; the user can also be notified that the filling has started and is in progress.
cancellFill()on the handle. In a GUI, this would be the result of a user action.
reportFinished()- called when the filling has finished successfully; the filled report is passed as a parameter. In a GUI, the user would be presented the filled report or would be able to save/export it.
reportFillError()- called when the filling ends in error; the exception that occurred is passed as a parameter.
reportCancelled()- called when the filling is aborted by the user.
JasperPrintobject could also be very large and might cause the JVM to run out of memory.
To increase the memory available for the Java application, first use the
when launching the JVM, since the default value for this parameter is fairly small.
However, if you do this with large datasets (for example, containing tens of thousands or
more records and resulting in documents that have thousands or more pages), the JVM
may run out of memory.
JasperReports offers a simple solution to the problem by introducing
the report virtualizer. The virtualizer is a simple interface
JRVirtualizer) that enables the reporting engine
to optimize memory consumption during report filling by removing parts of the
JasperPrint object from memory and storing them on disk or in other temporary
locations. If a report virtualizer is used during filling, the engine keeps only a limited
number of pages from the generated JasperPrint object at a time and serializes all the
other pages to a temporary storage location, usually the file system.
In virtualized form, a generated
JasperPrint document still behaves normally and can
be subject to exporting, printing, or viewing processes, and the impact on memory
consumption is minimal even when dealing with very large documents.
When produced using a virtualizer (which itself performs partial document serialization
into temporary files), once completed, a
JasperPrint document can itself be serialized
normally without any loss of information. During the serialization of a virtualized
JasperPrint object, the program puts back together all the pieces and a single
serialized file is produced. However, because this single file is probably very large,
simple deserialization would not make sense (in fact, it wouldn't be possible, as the JVM
would run out of memory, which is the reason for using virtualization in the first place).
So in order to reload into memory a virtualized document that was serialized to a
permanent storage facility, a report virtualizer is needed. This would be set using a local
thread variable by calling the following:
JRFileVirtualizer, which stores document pages on disk during the filling process to free up memory. Once a
JasperPrintobject is produced using a report virtualizer, it can be exported to other formats or viewed directly using the library's built-in viewer component, even though this document is not fully loaded at any one time. The virtualizer ensures that pages are deserialized and loaded from their temporary storage location as needed during exporting or display. A single
JRFileVirtualizerinstance can be shared across multiple report-filling processes so that the number of document pages kept in-memory at any one time will be limited by the virtualizer
maxSizeproperty, regardless of the number of reports that are generated simultaneously.
Because it works with temporary files on disk, the file virtualizer has a built-in
mechanism to remove those files after they are no longer needed (that is, after the
generated document or the virtualizer itself have been disposed of by the JVM). The
cleanup() method exposed by this virtualizer implementation can be also called
manually so that the temporary files are removed from disk right away instead of after
the finalization of the entities involved.
To ensure that no virtualization files are left over on disk by the application that uses the file virtualizer, all these temporary files are registered with the JVM so that they are deleted automatically when the JVM exits normally.
File.deleteOnExit() will accumulate JVM process memory on some
virtual machine implementations (see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513817); you should
avoid using this feature in long-running applications by turning it off using the
net.sf.jasperreports.virtualizer.files.delete.on.exit configuration property.
JRFileVirtualizerimplementation less effective.
Fortunately, there is another implementation of a file-based report virtualizer that uses a single swap file and can also be shared among multiple report-filling processes. Instead of having one temporary file per virtualized page, we create a single file into which all virtualized pages are stored to and then retrieved from.
This swap file virtualizer implementation is represented by the
JRSwapFileVirtualizer class that is
part of the JasperReports library core functionality, and works in combination with a
JRSwapFile instance representing the target
JRSwapFile instance has to be created and configured prior to being passed to the
swap virtualizer. You can create such an instance by specifying the target directory
where the swap file will be created, the size of the blocks allocated by the swap file, and
the minimum number of blocks by which the swap file will grow when its current size
represents an enhanced implementation of the JRSwapFile that only works with JRE
version 1.4 or later, because it uses a
java.nio.channels.FileChannel to perform
concurrent I/O on the swap file.
JRGzipVirtualizeris a convenient report virtualizer implementation that does not rely on the file system to temporarily store unused/virtualized document pages during the report filling. Rather, it optimizes memory consumption by compressing those pages in-memory using a GZIP algorithm. Tests indicate that memory consumption during large report-generating processes is reduced up to a factor of ten when the in-memory GZIP report virtualizer is used.
© 2001 - 2016 TIBCO Software Inc. www.jaspersoft.com