instantiates a compiler object and delegates the report compilation to it. By default,
BeanShell report compilers to the
If the report uses Java as language and no specific compiler has been set for this
language, the report compilation facade employs a built-in fall back mechanism that
picks the best Java-based report compiler available in the environment in which the
report compilation process takes place.
first reads the
configuration property called
users to override its built-in compiler-detection logic by providing the name of the report
compiler implementation to use directly. More on configuration properties for
customizing report compilation can be found later in this chapter.
This facade first tries to see if the JDT compiler from the Eclipse Foundation is available
in the application’s classpath. If it is, the
implementation is used.
The current JasperReports distribution ships the JDT compiler packed in the
If the JDT compiler is not available, the compilation facade then tries to locate the JDK
1.3–compatible Java compiler from Sun Microsystems. This is normally found in the
file that comes with the JDK installation.
If the JDK 1.3–compatible Java compiler is not in the classpath, the fall back search
mechanism looks for the JDK 1.2–compatible Java compiler, also from Sun
Microsystems, in case the application is running in an environment that has a JDK
version prior to 1.3 installed. This is also found in the
file from the JDK
If all these fail, the last thing the fall back mechanism does is to try to launch the
program from the command line in order to compile the temporarily
generated Java source file on the fly.
All these report compiler implementations are included for historical reasons. In the
beginning, JasperReports started with only the JDK 1.2–compatible report compiler.
Then the JDK 1.3–compatible report compiler was introduced. But both were slow. This
is why the
because the Jikes compiler proved to be up to ten times faster than the JDK-based Java
However, compiling reports on the fly (in the cases in which dynamic report templates
were required) proved to be problematic, especially in a web environment, because all
the aforementioned compilers worked only with files on disk and required a temporary
VB.NET PDF: Get Started with PDF Library
C#.NET rotate PDF pages, C#.NET search text in PDF Viewer, C# Online Dicom Viewer, C# Online Jpeg images VB.NET PDF: Get Started with .NET PDF Library Using VB. export text from pdf to excel; c# extract pdf text
working directory to store the generated Java source files and the corresponding class
files during the report-compilation process. This is why a new implementation was added
—one that relied on the BeanShell library for runtime expression evaluation. BeanShell
does not produce Java bytecode and can work with in-memory scripts that it interprets at
runtime. With the
deployment was simpler, but expression evaluation was slower and loss in performance
The addition of the JDT-based report compiler makes the whole process both faster and
simpler to deploy, as it does not require files on disk and its performance is comparable
to Jikes. Runtime report compilation is not an issue anymore, and simply putting the
file in the application’s classpath allows dynamic
report template creation without requiring any further settings.
Because it is a library, JasperReports offers various mechanisms for letting users
customize its behavior. One of these mechanisms is a complete set of configuration
properties. The following paragraphs list all the configuration properties that customize
report compilation. You can learn more about how JasperReports can be configured in
“Configuration Files” on page 272.
Such properties are used for indicating the name of the class that implements the
interface to be instantiated by the engine for a specific report language
when the default compilation is used through the
value for such a configuration property can be the name of one of the built-in
implementations of this interface shipped with the library as listed previously, or the
name of a custom-made implementing class.
One can configure report compilers for custom report languages and override the default
compiler mappings by setting JasperReports properties of the form
to the desired compiler
implementation class names. In particular, the mechanism that automatically chooses a
Java report compiler can be superseded by explicitly setting the
property to the name of one of the built-in
Java compiler classes or of a custom compiler implementation class.
Note that the classes implementing the
interface can also be used directly in
the programs without having to call them through the facade
C#: Use OCR SDK Library to Get Image and Document Text
C#: Use OCR SDK Library to Get Image and Document Text. C#.NET Online Tutorial for How to Extract Text from Tiff, Jpeg, Png, Gif, Bmp, and Scanned PDF Files. .net extract text from pdf; how to copy and paste pdf text
This was formerly known as the
The XML validation, which is on by default, can be turned off by setting the
configuration property to
. When turned off, the XML parser no longer validates the supplied JRXML
against its associated XSD. This might prove useful in some environments, although it is
When working with a Java class generating the type of a report compiler, further
customizations can be made using the following system properties, which only apply to
Formerly known as the
system property, this
supplies the classpath. JDK-based and Jikes-based compilers require that the classpath be
supplied as a parameter. They cannot use the current JVM classpath. The supplied
classpath resolves class references inside the Java code they are compiling.
This property is not used by the JDT-based report compiler, which simply uses the parent
application’s classpath during Java source file compilation.
This was formerly known as the
The temporary location for the files generated on the fly is by default the current working
directory. It can be changed by supplying a value to the
configuration property. This is used by
the JDT-based compiler only when it is requested that a copy of the on-the-fly generated
Java class be kept for debugging purposes as specified by the next configuration
property, because normally this report compiler does not work with files on disk.
This was formerly known as the
Sometimes, for debugging purposes, it is useful to have the generated
generated script in order to fix compilation problems related to report expressions. By
default, the engine deletes this file after report compilation, along with its corresponding
file. To keep it, however, set the configuration property
report compiler can use special JasperReports configuration
properties to configure the underlying JDT Java compiler. This report compiler collects
all the JasperReports configuration properties (the ones usually set in the
file) that start with the
and passes them to the JDT Java compiler when compiling the generated Java class to
evaluate report expressions.
One of the uses of this mechanism is to instruct the JDT compiler to observe Java 1.5
code compatibility. To do so, the following properties should be set:
This is demonstrated in the
sample distributed with
When the number of different report files that one has to deal with in a project is
significant, there is a need for automating repeating or re-occurring tasks that are to be
performed on those files.
From a design point of view, the most notable operation that needs to be performed on
report source files after they are finished and ready to be deployed is the report
compilation. Sometimes reports need to be decompiled in order to reproduce their
corresponding source files and perform additional design work on them, or when the
same modification needs to be performed identically on all reports.
For these re-occurring tasks, JasperReports provides built-in ready-to-use Ant task
Since report template compilation is more like a design-time job than a runtime one, a
custom Ant task has been provided with the library to simplify application development.
This Ant task is implemented by the
class. Its syntax and behavior are
very similar to the built-in
The report template compilation task can be declared like this, in a project’s
In the preceding example, the
should contain the
along with its other required libraries.
You can then use this user-defined Ant task to compile multiple JRXML report template
files in a single operation by specifying the root directory that contains those files or by
selecting them using file patterns.
Following is the list of attributes that can be used inside the Ant report compilation task
to specify the source files, the destination directory, and other configuration properties:
: Location of the JRXML report template files to be compiled. Required unless
elements are present.
: Location to store the compiled report template files (the same as the source
directory by default).
: Name of the class that implements the
interface to be used for
compiling the reports (optional).
: Flag to indicate whether the XML validation should be performed on
the source report template files (
: Location to store the temporarily generated files (the current working directory
: Flag to indicate if the temporary Java files generated on the fly should be kept
and not deleted automatically (
The report template compilation task supports nested
elements, just like the Ant
To see this in action, check the
sample provided with the
project’s source files.
Sometimes it happens that report templates are to be found only in their compiled form.
The source report template files might have been lost and we might have only the
compiled report template on which we need to make some modifications.
In such cases, the Ant task for decompiling report template files that JasperReports
provides becomes very handy. It is implemented by the
class and its declaration inside a
should be as follows:
</taskdef>In the above example, the classpath should contain the
jasperreports-x.x.x.jar file along with its other required
This task works similarly to the report compilation task, but it does the reverse operation.
The files to be decompiled can be specified using the
attribute for their root
folder or, for more sophisticated file match patterns, a nested
tag. The output
folder for the generated files is specified using the
This task is demonstrated in the
sample provided with
the project source files.
Although JasperReports always guarantees backward compatibility of report templates
when upgrading to a newer version, sometimes tags or attributes in JRXML are
deprecated and replaced with newer ones that offer enhanced capabilities. So while the
deprecated attributes and tags still work, it is always advisable to use the latest syntax
and thus get rid of the deprecation warnings.
Upgrading a report template to the latest JasperReports syntax is very easy; all that needs
to be done is to load the report and save it again using the API's utility classes, such as
This operation can be automated for any number of files using the Ant report update task
provided by the JasperReports library in the
class, which should have the
following definition in a
This task is useful also in situations where the same modification needs to be applied on
a number of different report files. The required modifications can be performed using the
JasperReport API after the report design object has been loaded but before it is saved
Custom implementations of the
interface can be registered
with the Ant report update task using nested
tags, as seen in the
sample provided with the project.
Documents you may be interested
Documents you may be interested