PK
@Aoa, mimetypeapplication/epub+zipPK @A iTunesMetadata.plistL
This chapter guides you through the basics of testing your Oracle SQLJ installation and configuration and running a simple application.
This chapter discusses the following topics:
This section discusses basic assumptions about your environment and requirements of your system so that you can run SQLJ, covering the following topics:
The following assumptions are made about the system on which you will be running the Oracle SQLJ implementation:
You have a standard Java environment that is operational on your system. This would typically be using a Sun Microsystems Java Development Kit (JDK), but other implementations of Java will work. Ensure that you can run Java (typically java
) and the Java compiler (typically javac
).
To translate and run SQLJ applications on a Sun JDK, you must use JDK 1.5.x or JDK 1.6.x. You must use the JDBC driver of the same version as that of SQLJ, can be thin or OCI8 driver
Note: A Java run-time environment (JRE), such as the one installed with Oracle Database 11g, is not by itself sufficient for translating SQLJ programs. However, a JRE is sufficient for running SQLJ programs that have already been translated and compiled. |
You can already run JDBC applications in your environment.
See also: Oracle Database JDBC Developer's Guide and Reference for more information about JDBC drivers |
The following are required to use the Oracle SQLJ implementation:
A database system that is accessible using your JDBC driver
Class files for the SQLJ translator
Translator-related classes are available in the following file:
ORACLE_HOME
/sqlj/lib/translator.jar
Class files for the SQLJ run time.
ORACLE_HOME
/sqlj/lib/runtime12.jar
Note: runtime12ee.jar has been deprecated since Oracle Database 11g Release 1 (11.1). Use runtime12.jar instead. |
To ensure that you have a fully working environment, you must consider several aspects of your environment: SQLJ and its code generation mode, JDBC, and the JDK.
Note: Code generation is determined by the SQLJ-codegen option. Refer to "Code Generation (-codegen)" for more information. |
The following is a typical environment setup for Oracle-specific code generation:
SQLJ code generation: -codegen=oracle
(default)
SQLJ translation library: translator.jar
SQLJ run-time library: runtime12.jar
JDBC drivers: Oracle 11g release 2 (11.2)
JDK version: 1.5.x or 1.6.x
Note: If you are running against different JDBC versions, then translate against the earlier version. |
You can run the application against a JDK version that is at least as high as the version you translated the code under.
You must keep in mind the following points regarding backward compatibility of the Oracle SQLJ implementation:
Code generated with an earlier release of the SQLJ translator can continue to run and compile against current run-time libraries. However, this is subject to the cross-compatibility limitations discussed in "Environment Considerations".
Oracle-specific translator output, that is, code generated with the default -codegen=oracle
setting, must be created and executed using the runtime12.jar
library. In addition:
Such code will be executable under future Oracle JDBC and SQLJ implementations.
Such code, however, will not be executable under earlier releases of Oracle JDBC drivers and Oracle SQLJ run time. In these circumstances, you will have to retranslate the code.
After you have verified that the preceding assumptions and requirements are satisfied, you must check your SQLJ installation. You must:
Following are the release-specific notes regarding availability of SQLJ and its demo applications:
SQLJ and its demo applications are available from the Oracle Technology Network (OTN) at the following location:
http://www.oracle.com/technology/sample_code/tech/java/sqlj_jdbc/sqlj.html
For Oracle Database 11g, SQLJ and its demo applications are included with the installation.
Verify that the following directories have been installed and are populated:
Directories for JDBC
Refer to the Oracle Database JDBC Developer's Guide and Reference for information about JDBC files that should be installed on your system.
Directories for SQLJ
Installing the Oracle Database 11g Java environment includes, among other things, installing a sqlj
directory under your ORACLE_HOME
directory. The sqlj
directory contains the following subdirectories:
demo
(demo applications, including some referenced in this chapter)
lib
(.jar
files containing class files for SQLJ)
Check whether all these directories have been created and populated, especially lib
.
The ORACLE_HOME
/bin
directory contains utilities for all Java product areas, including the SQLJ and JPublisher executable files.
Ensure that the PATH
and CLASSPATH
environment variables have the necessary settings for the Oracle SQLJ implementation. Set the PATH
and CLASSPATH
environment variables as follows for the Oracle SQLJ implementation:
Setting PATH
To run the sqlj
script, which invokes the SQLJ translator, without having to fully specify its path, verify that the PATH
environment variable has been updated to include the following:
ORACLE_HOME/bin
Use backslash (\) for Microsoft Windows. Replace ORACLE_HOME
with your actual Oracle home directory.
Setting CLASSPATH
Update the CLASSPATH
environment variable to include the current directory as well as the following:
ORACLE_HOME/sqlj/lib/translator.jar
Use backslash (\) for Microsoft Windows. Replace ORACLE_HOME
with your actual Oracle home directory.
Include the following run-time library in the CLASSPATH
:
ORACLE_HOME/sqlj/lib/runtime12.jar
In addition, you must include one of the following JDBC JARs in the CLASSPATH
:
ORACLE_HOME/jdbc/lib/ojdbc5*.jar ORACLE_HOME/jdbc/lib/ojdbc6*.jar
Note: To translate or run SQLJ programs in JDK 1.5.x environment, you should haveojdbc5.jar in the classpath and to translate or run SQLJ programs in JDK 1.6.x environment, you should have ojdbc6.jar in the classpath. Ensure that the correct JDBC JAR is picked up at runtime for connecting to Oracle Database. |
Note: You will not be able to run the SQLJ translator if you do not add a run-time library. You must specify a run-time library as well as the translator library in theCLASSPATH .
To see if SQLJ is installed correctly, and to see the version information for SQLJ, JDBC, and Java, run the following command: % sqlj -version-long |
The sqljutl
package is required for online checking of stored procedures and functions in Oracle Database instance. Beginning with Oracle8i Database release 8.1.5, it is installed automatically under the SYS
schema during installation of the server-side Java virtual machine (JVM) for a Java-enabled database. If your database is not Java-enabled, then you will have to manually install this package.
If you want to verify the installation of sqljutl
, then issue the following SQL command from SQL*Plus:
describe sys.sqljutl
This should result in a brief description of the package.
If you get a message indicating that the package cannot be found, or if you want to install an updated version of the package, then you can install it by using SQL*Plus to run the sqljutl.sql
script (or sqljutl8.sql
for Oracle8i Database), which is located at:
ORACLE_HOME/sqlj/lib/sqljutl.sql
You can test your database, JDBC, and SQLJ setup using demo applications defined in the following source files:
TestInstallCreateTable.java
TestInstallJDBC.java
TestInstallSQLJ.sqlj
TestInstallSQLJChecker.sqlj
There is also a Java properties file, connect.properties
, that helps you set up your database connection. You must edit this file to set appropriate user, password, and URL values.
The demo applications discussed here are provided with your SQLJ installation in the demo
directory:
ORACLE_HOME/sqlj/demo
You may have to edit some of the source files and translate and compile them, as appropriate. The demo applications provided with the Oracle SQLJ implementation refer to tables on Oracle Database account with user name scott
and password tiger
. Most Oracle Database installations have this account. You can substitute other values for scott
and tiger
if desired.
Note: Running the demo applications requires that thedemo directory be the current directory, and that the current directory (". ") should be specified in the CLASSPATH . |
This section covers the following topics:
This section describes how to update the connect.properties
file to configure your Oracle connection for run time. The file is in the demo
directory and looks something like the following:
Note: In the Oracle Database 11g JDBC implementation, database URL connection strings using SIDs are deprecated. Following is an example, whereorcl is the SID:
jdbc:oracle:thin:@localhost:1521:orcl This would now generate a warning, but not a fatal error. Instead, you are encouraged to use database service names, such as jdbc:oracle:thin:@localhost:1521/myservice Refer to the Oracle Database JDBC Developer's Guide and Reference for information about database service names. |
# Users should uncomment one of the following URLs or add their own. # (If using Thin, edit as appropriate.) #sqlj.url=jdbc:oracle:thin:@localhost:1521/myservice #sqlj.url=jdbc:oracle:oci:@ # # User name and password here sqlj.user=scott sqlj.password=tiger
Connecting with an Oracle JDBC Driver
Use oci
in the connection string for Oracle JDBC OCI driver in any new code. For backward compatibility, however, oci8
is still accepted. Therefore, you do not have to change existing code.
If you are using the JDBC Thin driver, then uncomment the thin
URL line in connect.properties
and edit it as appropriate for your Oracle connection. Use the same URL that was specified when your JDBC driver was set up.
The following tests assume a table called SALES
. Compile and run TestInstallCreateTable
as follows:
% javac TestInstallCreateTable.java % java TestInstallCreateTable
This will create the table for you if the database and the JDBC driver are working and the connection is set up properly in the connect.properties
file.
Note: If you already have a table calledSALES in your schema and do not want it altered, edit TestInstallCreateTable.java to change the table name. Otherwise, your original table will be dropped and replaced. |
If you do not want to use TestInstallCreateTable
, then you can create the SALES
table using the following SQL statement:
CREATE TABLE SALES ( ITEM_NUMBER NUMBER, ITEM_NAME CHAR(30), SALES_DATE DATE, COST NUMBER, SALES_REP_NUMBER NUMBER, SALES_REP_NAME CHAR(20));
If you want to further test Oracle JDBC driver, then use the TestInstallJDBC
demo. Verify that your connection is set up properly in connect.properties
. Then, compile and run TestInstallJDBC
, as follows:
% javac TestInstallJDBC.java % java TestInstallJDBC
The program should print:
Hello, JDBC!
Now translate and run the TestInstallSQLJ
demo, a SQLJ application that has functionality similar to that of TestInstallJDBC
. Use the following command to translate the source:
% sqlj TestInstallSQLJ.sqlj
Note that this command also compiles the application.
On a UNIX environment, the sqlj
script is in ORACLE_HOME
/bin
, which should already be in the PATH
. On Windows, use the sqlj.exe
executable in the bin
directory. The SQLJ translator.jar
file has the class files for the SQLJ translator and run time. It is located in ORACLE_HOME
/sqlj/lib
and should already be in the CLASSPATH
.
Now run the application as follows:
% java TestInstallSQLJ
The program should print:
Hello, SQLJ!
If the SQLJ translator is able to connect to a database, then it can provide online semantics-checking of your SQL operations during translation. The SQLJ translator is written in Java and uses JDBC to get information it needs from a database connection that you specify. You provide the connection parameters for online semantics-checking using the sqlj
script command line or using a SQLJ properties file, which is sqlj.properties
by default.
While still in the demo
directory, edit the sqlj.properties
file and update, comment, or uncomment the sqlj.password
, sqlj.url
, and sqlj.driver
lines, as appropriate, to reflect your database connection information. For assistance, refer to the comments in the sqlj.properties
file.
Following is an example of what the appropriate driver, URL, and password settings might be if you are using Oracle JDBC OCI driver.
sqlj.url=jdbc:oracle:oci:@ sqlj.driver=oracle.jdbc.OracleDriver sqlj.password=tiger
Online semantics-checking is enabled as soon as you specify a user name for the translation-time connection. You can specify the user name either by uncommenting the sqlj.user
line in the sqlj.properties
file or by using the -user
command-line option. The user
, password
, url
, and driver
options all can be set either on the command line or in the properties file.
You can test online semantics-checking by translating the TestInstallSQLJChecker.sqlj
file located in the demo
directory, as follows (or using another user name, if appropriate):
% sqlj -user=scott TestInstallSQLJChecker.sqlj
This should produce the following error message if you are using one of Oracle JDBC drivers:
TestInstallSQLJChecker.sqlj:41: Warning: Unable to check SQL query. Error returned by database is: ORA-00904: invalid column name
Edit TestInstallSQLJChecker.sqlj
to fix the error on line 41. The column name should be ITEM_NAME
instead of ITEM_NAMAE
. Once you make this change, you can translate and run the application without error using the following commands:
% sqlj -user=scott TestInstallSQLJChecker.sqlj % java TestInstallSQLJChecker
If everything works, then the following line is displayed:
Hello, SQLJ Checker!
Profiles and profile customization are introduced in "SQLJ Profiles". This appendix presents more technical detail and discusses customizer options and how to use customizers other than the default Oracle customizer.
There is also discussion of Oracle specialized customizers, particularly the SQLCheckerCustomizer
for semantics-checking profiles, and the AuditorInstaller
for installing auditors for debugging.
The following topics are covered:
Note: If you use the default Oracle-specific code generation (-codegen=oracle ), the discussion in this appendix does not pertain to your application. |
SQLJ profiles contain information about your embedded SQL operations, with a separate profile being created for each connection context class that your application uses. Profiles are created during the SQLJ translator code generation phase and customized during the customization phase. Customization enables your application to use vendor-specific database features. Separating these vendor-specific operations into your profiles enables the rest of your generated code to remain generic.
Each profile contains a series of entries for the SQLJ statements that use the relevant connection context class, where each entry corresponds to one SQL operation in your application.
Profiles exist as serialized objects stored in resource files packaged with your application. Because of this, profiles can be loaded, read, and modified (added to or recustomized) at any time. When profiles are customized, information is only added, never removed. Multiple customizations can be made without losing preceding customizations, so that your application maintains the capability to run in multiple environments. This is known as binary portability.
For profiles to have binary portability, SQLJ industry-standard requirements have been met in the Oracle SQLJ implementation.
During code generation, the translator creates each profile as follows:
It creates a profile object as an instance of the sqlj.runtime.profile.Profile
class.
It inserts information about your embedded SQL operations into the profile object, for SQLJ statements that use the relevant connection context class.
It serializes the profile object into a Java resource file, referred to as a profile file, with a .ser
file name extension.
Note: The Oracle SQLJ implementation provides an option to have the translator automatically convert these.ser files to .class files. The.ser files are not supported by some browsers, and can be cumbersome when loading translated applications into the server. However, this prevents any further customization of the profile. For information, see "Conversion of .ser File to .class File (-ser2class)". |
As discussed in "Code Generation", profile file names for application Foo
are of the form:
Foo_SJProfilen.ser
SQLJ generates Foo_SJProfile0.ser
, Foo_SJProfile1.ser
, and so on, as needed, depending on how many connection context classes you use in your code. Or, if the -ser2class
option is enabled, then SQLJ generates Foo_SJProfile0.class
, Foo_SJProfile1.class
, and so on.
Each profile has a getConnectedProfile()
method that is called during SQLJ runtime. This method returns something equivalent to a JDBC Connection
object, but with added functionality. This is further discussed in "Functionality of a Customized Profile at Run Time".
Note: Referring to a "profile object" indicates that the profile is in its original nonserialized state. Referring to a "profile file" indicates that the profile is in its serialized state in a.ser file. |
Following is a sample SQLJ executable statement with the profile entry that would result. For simplicity, the profile entry is presented as plain text with irrelevant portions omitted.
Note that in the profile entry, the host variable is replaced by JDBC syntax (the question mark).
Presume the following declaration:
#sql iterator Iter (double sal, String ename);
And presume the following executable statements:
String empname = 'Smith'; Iter it; ... #sql it = { SELECT ename, sal FROM emp WHERE ename = :empname };
================================================================= ... #sql { SELECT ename, sal FROM emp WHERE ename = ? }; ... PREPARED_STATEMENT executed through EXECUTE_QUERY role is QUERY descriptor is null contains one parameter 1. mode: IN, java type: java.lang.String (java.lang.String), sql type: VARCHAR, name: ename, ... result set type is NAMED_RESULT result set name is Iter contains 2 result columns 1. mode: OUT, java type: double (double), sql type: DOUBLE, name: sal, ... 2. mode: OUT, java type: java.lang.String (java.lang.String), sql type: VARCHAR, name: ename, ... =================================================================
Note: This profile entry is presented here as text for convenience only; profiles are not actually in text format. They can be printed as text, however, using the SQLJ-P-print option, as discussed in "Overview of Customizer Harness Options". |
When using ISO SQLJ code, running the sqlj
script on a SQLJ source file includes an automatic customization process, where each profile created during the code generation phase is customized for use with your particular database. The default customizer is Oracle customizer, oracle.sqlj.runtime.OraCustomizer
, which optimizes your profiles to use type extensions and performance enhancements specific to Oracle11g.
You can also run the sqlj
script to customize profiles created previously. On the SQLJ command line, you can specify .ser
files individually, JAR files containing .ser
files, or both.
Note:
|
Regardless of whether you use Oracle customizer or an alternative customizer, SQLJ uses a front-end customization utility known as the customizer harness in accomplishing your customizations.
When you run SQLJ, you can specify customization options for the customizer harness (for general customization settings that apply to any customizer you use) and for your customizer (for settings used by the particular customizer). In either case, you can specify these options either on the command line or in a properties file. This is discussed in "Customization Options and Choosing a Customizer".
A customizer is required to be a JavaBeans component adhering to the standard JavaBeans API to expose its properties, and must implement the sqlj.runtime.profile.util.ProfileCustomizer
interface, which specifies a customize()
method. For each profile to be customized, the customizer harness calls the customize()
method of the customizer object.
Oracle customizer meets the preceding requirements and is defined in the oracle.sqlj.runtime.OraCustomizer
class.
The SQLJ customization process during translation consists of the following steps, as applicable, either during the customization stage of an end-to-end SQLJ run, or when you run SQLJ to customize existing profiles only:
SQLJ instantiates and invokes the customizer harness and passes it any general customization options you specified.
The customizer harness instantiates the customizer you are using and passes it any customizer-specific options you specified.
When you run SQLJ for customization only, specifying one or more JAR files on the command line, the customizer harness discovers and extracts the profile files within these JAR files.
The customizer harness deserializes each profile file into a profile object (.ser
files automatically created during an end-to-end SQLJ run, .ser
files specified on the command line for customization only, or .ser
files extracted from JAR files specified on the command line for customization only).
If the customizer you use requires a database connection, the customizer harness establishes that connection.
For each profile, the harness calls the customize()
method of the customizer object instantiated in step 2 (customizers used with SQLJ must have a customize()
method).
For each profile, the customize()
method typically creates and registers a profile customization within the profile. This depends on the intended functionality of the customizer, however. Some might have a specialized purpose that does not require a customization to be created and registered in this way.
The customizer harness reserializes each profile and puts it back into a .ser
file.
When you run SQLJ for customization only, specifying one or more JAR files on the command line, the customizer harness recreates the JAR contents, inserting each customized .ser
file to replace the original corresponding uncustomized .ser
file.
Note:
|
When the harness calls the customize()
method to customize a profile, it passes in the profile object, a SQLJ connection context object (if you are using a customizer that requires a connection), and an error log object (which is used in logging error messages during the customization).
The same error log object is used for all customizations throughout a single running of SQLJ, but its use is transparent. The customizer harness reads messages written to the error log object and reports them in real-time to the standard output device (whatever SQLJ uses, typically your screen).
Recall that each profile has a set of entries, where each entry corresponds to a SQL operation. (These would be the SQL operations in your application that use instances of the connection context class associated with this profile.)
A customize()
method implements special processing on these entries. It could be as simple as checking each entry to verify its syntax, or it could be more complicated, such as creating new entries that are equivalent to the original entries but are modified to use features of your particular database.
Note:
|
The customizer harness outputs error and status messages in much the same way as the SQLJ translator, outputting them to the same output device. None of the warnings regarding customization are suppressible, however.
Error messages reported by the customizer harness fall into four categories:
Unrecognized or illegal option
Connection instantiation error
Profile instantiation error
Customizer instantiation error
Status messages reported by the customizer harness during customization enable you to determine whether a profile was successfully customized. They fall into three categories:
Profile modification status
JAR file modification status
Name of backup file created (if the customizer harness backup
option is enabled)
Additional customizer-specific errors and warnings might be reported by the customize()
method of the particular customizer.
During customization, the profile customizer writes messages to its error log, and the customizer harness reads the log contents in real-time and outputs these messages to the SQLJ output device, along with any other harness output. You never have to access error log contents directly.
A customized profile is a static member of the connection context class with which it is associated. For each SQLJ statement in your application, the SQLJ run time determines the connection context class and instance associated with that statement, then uses the customized profile of the connection context class, together with the underlying JDBC connection of the particular connection context instance, to create a connected profile. This connected profile is the vehicle that the SQLJ run time uses in applying vendor-specific features to the execution of your SQLJ application.
This section discusses options for profile customization, which fall into three categories:
Options you specify to the customizer harness, which apply to whatever customizer you use.
This includes general options, connection options, and options that invoke specialized customizers.
Customizer-specific options you specify to your customizer through the customizer harness.
SQLJ options, which determine basic aspects of customization, such as whether to customize at all and which customizer to use.
All categories of options are specified through the SQLJ command line or properties files.
The following topics are included in this section:
To choose a customizer other than the default Oracle customizer, you can use either the customizer harness customizer
option (discussed in "Overview of Customizer Harness Options") or the SQLJ -default-customizer
option (discussed in "SQLJ Translator Options for Profile Customization").
The customizer harness provided with the Oracle SQLJ implementation offers a number of options that are not specific to a particular customizer. The harness uses these options in its front-end coordination of the customization process.
Customizer harness option settings on the SQLJ command line have the following syntax:
-P-option=value
Alternatively, in a SQLJ properties file:
profile.option=value
Enable boolean options (flags) either with:
-P-option
or:
-P-option=true
Boolean options are disabled by default, but you can explicitly disable them with:
-P-option=false
This option syntax is also discussed in "Options to Pass to the Profile Customizer (-P)" and "Properties File Syntax".
The customizer harness supports the following general options:
backup
: Save a backup copy of the profile before customizing it.
context
: Limit customizations to profiles associated with the listed connection context classes.
customizer
: Specify the customizer to use.
digests
: Specify digests for JAR file manifests (relevant only if specifying JAR files to customize).
help
: Display customizer options (specified only in SQLJ command line).
verbose
: Display status messages during customization.
The customizer harness supports the following options for customizer database connections. Currently, these are used by Oracle customizer if you enable its optcols
option for column definitions (for performance optimization). In addition, they are used by the SQLCheckerCustomizer
if you use this specialized customizer to perform online semantics-checking on profiles.
user
: Specify the user name for the connection used in this customization.
password
: Specify the password for the connection used in this customization.
url
: Specify the URL for the connection used in this customization.
driver
: Specify the JDBC driver for the connection used in this customization.
For information about the Oracle customizer optcols
flag, see "Oracle Customizer Column Definition Option (optcols)". For information about the SQLCheckerCustomizer
, see "SQLCheckerCustomizer for Profile Semantics-Checking".
The following commands function as customizer harness options, but are implemented through specialized customizers provided with the Oracle SQLJ implementation.
debug
: Insert debugging information into the specified profiles, to be output at run time. This is a shortcut to invoke the Oracle SQLJ AuditorInstaller
, which is described in "AuditorInstaller Customizer for Debugging".
print
: Output the contents of the specified profiles, in text format.
verify
: Perform semantics-checking on a profile that was produced during a previous execution of the SQLJ translator (equivalent to semantics-checking performed on source code during translation). This is a shortcut to invoke Oracle SQLJ SQLCheckerCustomizer
, which is described in "SQLCheckerCustomizer for Profile Semantics-Checking".
This section describes general options supported by the customizer harness.
Use the backup
flag to instruct the harness to save a backup copy of each .jar
file and standalone .ser
file before replacing the original. (Separate backups of .ser
files that are within .jar
files are not necessary.)
Backup file names are given the extension .bak
n
, where n
indicates digits used as necessary where there are similarly named files. For each backup file created, an informational message is issued.
If an error occurs during customization of a standalone .ser
file, then the original .ser
file is not replaced and no backup is created. Similarly, if an error occurs during customization of any .ser
file within a JAR file, then the original JAR file is not replaced and no backup is created.
The command-line syntax for this option is:
-P-backup<=true|false>
Command-line example is:
-P-backup
Properties file syntax is:
profile.backup<=true|false>
Default value is:
false
Use the context
option to limit customizations to profiles that correspond to the specified connection context classes. Fully qualify the class names and use a comma-delimited list to specify multiple classes. For example:
-P-context=sqlj.runtime.ref.DefaultContext,foo.bar.MyCtxtClass
There must be no space on either side of the comma.
If this option is not specified, then all profiles are customized, regardless of their associated connection context classes.
Command-line syntax is:
-P-context=ctx_class1<,ctx_class2,...>
Command-line example is:
-P-context=foo.bar.MyCtxtClass
Properties file syntax is:
profile.context=ctx_class1<,ctx_class2,...>
Properties file example is:
profile.context=foo.bar.MyCtxtClass
Use the customizer
option to specify which customizer to use. Fully qualify the class name, such as in the following example:
-P-customizer=oracle.sqlj.runtime.util.OraCustomizer
If you do not set this option, then SQLJ will use the customizer specified in the SQLJ -default-customizer
option. Unless set otherwise, this is the following:
oracle.sqlj.runtime.util.OraCustomizer
Command-line syntax is:
-P-customizer=customizer_class
Command-line example is:
-P-customizer=a.b.c.MyCustomizer
Properties file syntax is:
profile.customizer=customizer_class
Properties file example is:
profile.customizer=a.b.c.MyCustomizer
Default value is:
None
When a JAR file is produced, the JAR utility can optionally include one or more digests for each entry, based on one or more specified algorithms, so that the integrity of the JAR file entries can later be verified. Digests are similar conceptually to checksums, for readers familiar with those.
If you are customizing profiles in a JAR file and want the JAR utility to add new digests (or update existing digests) when the JAR file is updated, use the digests
option to specify a comma-delimited list of one or more algorithms. These are the algorithms that the JAR utility will use in creating the digests for each entry. The JAR utility produces one digest for each algorithm for each JAR file entry in the JAR manifest file. Specify algorithms as follows:
-P-digests=SHA,MD5
There must be no space on either side of the comma.
In this example, there will be two digests for each entry in the JAR manifest file: an SHA
digest and an MD5
digest.
Note: Visit the Sun site more information about JAR manifest file. |
Command-line syntax is:
-P-digests=algo1<,algo2,...>
Command-line example is:
-P-digests=SHA,MD5
Properties file syntax is:
profile.digests=algo1<,algo2,...>
Properties file example is:
profile.digests=SHA,MD5
Default value is:
SHA,MD5