Oracle9i Java Developer's Guide Release 1 (9.0.1) Part Number A90209-01 |
|
This chapter describes what you need to know to install and configure Oracle JVM within your database. To configure Java memory, see the "Java Memory Usage" section in Chapter6, "Oracle9i Java Application Performance".
If you install Oracle9i with the Oracle JVM option, the database is Java-enabled. That is, it is ready to run Java stored procedures, JDBC, SQLJ, CORBA/EJB objects, Servlets, and JavaServer Pages.
Configure the Oracle JVM option within the database template. This is the recommended method for Java installation.
The Oracle Database Configuration Assistant allows you to create database templates for defining what each database instance installation will contain. Choose the Oracle JVM option to have the Java platform installed within your database. See the Oracle Database Configuration Assistant documentation for more information on template creation.
After installation, you must unlock the following three users:
By default, all database users are locked. These three users must be unlocked by a system administrator in order for Servlets, JavaServer Pages, EJB applications, or CORBA applications to work correctly.
If you have already installed your Oracle9i database without Oracle JVM, you can add Java to your database through the modify mode of the Oracle9i Database Configuration Assistant. The modify mode enables you to choose the features, such as Oracle JVM, that you would like installed on top of an existing Oracle9i database.
When you install Oracle JVM as part of your normal Oracle9i installation, you will encounter configuration requirements for Oracle JVM within the Oracle9i Database Configuration Assistant and the Oracle Net Assistant.
The main configuration for Java classes within Oracle9i includes configuring Java memory requirements, the type of database processes, and the underlying connection protocol to the server.
JAVA_POOL_SIZE
and 50 MB of SHARED_POOL_SIZE
. See "Java Memory Usage" for information on configuring these parameters.
The networking protocol is referred to as the "presentation layer" within the Oracle9i documentation. However, it is not the same as the presentation layer in the OSI model. Instead, it is a protocol-based server framework that accepts incoming network requests and processes these requests.
Presentation Protocol |
Description |
---|---|
TTC |
Processes incoming Oracle Net requests for database SQL services from Oracle tools (such as SQL*Plus) and customer-written applications (using Forms, Pro*C, or the OCI). See "Configuring Multi-Threaded Server" in Chapter 9 of the Oracle9i Net Services Administrator's Guide for configuration information. |
GIOP |
Accepts IIOP or IIOP over SSL requests for CORBA or EJB applications. See the Oracle9i Enterprise JavaBeans Developer's Guide and Reference or the Oracle9i CORBA Developer's Guide and Reference for configuration information. |
HTTP |
Accepts HTTP requests for Servlets or JavaServer Pages. |
You will require a different configuration for your database type and connection configuration, depending on the type of Java application, as listed below:
Java API | Database Type | Connection Configuration |
---|---|---|
Java stored procedures |
Java stored procedures can run either in dedicated server mode or shared server mode. If you are primarily developing Java stored procedures, you can run them in the dedicated server configuration. |
Java clients or PL/SQL clients that trigger a Java stored procedure connect over a Oracle Net connection. See the Oracle9i Net Services Administrator's Guide for information on configuring an Oracle Net connection. |
Enterprise Java Beans (EJB) or CORBA |
EJB and CORBA applications run only in the shared server configuration. See the Oracle9i Net Services Administrator's Guide for information on configuring shared servers. |
EJB and CORBA clients use the CORBA Internet Inter-Orb Protocol (IIOP). See the Oracle9i Enterprise JavaBeans Developer's Guide and Reference or the Oracle9i CORBA Developer's Guide and Reference books for information on IIOP configuration. |
Servlets or |
Servlets and JavaServer Pages run only in the shared server configuration. See the Oracle9i Net Services Administrator's Guide for information on configuring shared servers. |
Servlets and JavaServer Pages run only over HTTP. See the Oracle9i Oracle Servlet Engine User's Guide for more information. |
Both Java stored procedures and EJB or CORBA applications |
If you are combining both EJB and CORBA applications with Java stored procedures in a single application, you can configure both application types as follows: |
You must configure both a TTC and an IIOP connection. |
To configure the database to run Java stored procedures, you must decide whether you want the database to run in dedicated server mode or shared server mode.
Java, SQL, or PL/SQL clients, which execute Java stored procedures on the server, connect to the database over a TTC connection. For a full description of how to configure the Oracle Net TTC connection, see the Oracle9i Net Services Administrator's Guide.
Clients access EJB and CORBA applications in the database over an Inter-Orb Protocol (IIOP) connection. IIOP is an implementation of GIOP over TCP/IP. To support an IIOP connection, you must configure the database in shared server mode with the General Inter-Orb Protocol (GIOP) presentation.
Oracle9i also supports the use of authentication data such as certificates and private keys required for use by SSL in combination with both types of GIOP protocols-- regular GIOP and session-based GIOP.
For a complete description of how to configure shared server, see the Oracle9i Net Services Administrator's Guide. For a full description of how to configure the GIOP presentation, see the Oracle9i Enterprise JavaBeans Developer's Guide and Reference or the Oracle9i CORBA Developer's Guide and Reference books.
Clients access Servlets and JavaServer Pages in the database or the middle-tier over the HTTP protocol.
Installing Oracle JVM creates the PL/SQL package DBMS_JAVA
. Some entrypoints of DBMS_JAVA
are for your use; others are only for internal use. The corresponding Java class DbmsJava
provides methods for accessing RDBMS functionality from Java.
The DBMS_JAVA
package supplies the following entrypoints:
FUNCTION longname (shortname VARCHAR2) RETURN VARCHAR2
Return the full name from a Java schema object. Because Java classes and methods can have names exceeding the maximum SQL identifier length, Oracle JVM uses abbreviated names internally for SQL access. This function simply returns the original Java name for any (potentially) truncated name. An example of this function is to print the fully qualified name of classes that are invalid:
select dbms_java.longname (object_name) from user_objects where object_type = 'JAVA CLASS' and status = 'INVALID'; FUNCTION shortname (longname VARCHAR2) RETURN VARCHAR2
You can specify a full name to the database by using the shortname()
routine of the DBMS_JAVA
package, which takes a full name as input and returns the corresponding short name. This is useful when verifying that your classes loaded by querying the USER_OBJECTS
view.
Refer to "Shortened Class Names" and the Oracle9i Java Stored Procedures Developer's Guide for examples of these functions.
FUNCTION get_compiler_option(what VARCHAR2, optionName VARCHAR2) PROCEDURE set_compiler_option(what VARCHAR2, optionName VARCHAR2,
value VARCHAR2) PROCEDURE reset_compiler_option(what VARCHAR2, optionName VARCHAR2)
These three entry points control the options of the Oracle9i Java and SQLJ compiler that Oracle9i delivers. See "Compiling Java Classes" for an example of these options. Additionally, both the Oracle9i Java Stored Procedures Developer's Guide and the Oracle9i SQLJ Developer's Guide and Reference document the options and these entry points.
PROCEDURE set_output (buffersize NUMBER)
This procedure redirects the output of Java stored procedures and triggers to the DBMS_OUTPUT
package. See "Redirecting Output on the Server" for an example.
PROCEDURE loadjava(options varchar2) PROCEDURE loadjava(options varchar2, resolver varchar2) PROCEDURE dropjava(options varchar2)
These procedures allow you to load and drop classes within the database using a call, rather than through the loadjava
or dropjava
command-line tools. To execute within your Java application, do the following:
call dbms_java.loadjava('... options...'); call dbms_java.dropjava('... options...');
The options are identical to those specified for the loadjava
and dropjava
command-line tools. Each option should be separated by a blank. Do not separate the options with a comma. The only exception to this is the loadjava
-resolver
option, which contains blanks. For -resolver
, specify all other options first, separate these options by a comma, and then specify the -resolver
options, as follows:
call dbms_java.loadjava('... options...', 'resolver_options');
Do not specify the following options, because they relate to the database connection for the loadjava
command-line tool: -thin,
-oci,
-user,
-password
. The output is directed to stderr.
For more information on the available options, see the Oracle9i Java Tools Reference for complete information on loadjava
.
PROCEDURE grant_permission( grantee varchar2,
permission_type varchar2,
permission_name varchar2,
permission_action varchar2 )
PROCEDURE restrict_permission( grantee varchar2,
permission_type varchar2,
permission_name varchar2,
permission_action varchar2)
PROCEDURE grant_policy_permission( grantee varchar2,
permission_schema varchar2,
permission_type varchar2,
permission_name varchar2)
PROCEDURE revoke_permission(permission_schema varchar2,
permission_type varchar2,
permission_name varchar2,
permission_action varchar2)
PROCEDURE disable_permission(key number)
PROCEDURE enable_permission(key number)
PROCEDURE delete_permission(key number)
These entry points control the JVM permissions. See "Setting Permissions" for a description and example of these options.
PROCEDURE start_debugging(host varchar2, port number,
timeout number)
PROCEDURE stop_debugging
PROCEDURE restart_debugging(timeout number)
These entry points start and stop the debug agent when debugging. See "Debugging Server Applications" for a description and example of these options.
To run Java between the client and server, your client system must perform the following:
2. Set up Environment Variables.
The client requires JDK 1.1.6 or later. Solaris 2.6 bundles JDK 1.1.3, which does not work with our samples. Verify that your PATH includes JDK 1.1.6 or later and does not include JDK 1.1.3. To confirm what version of the JDK you are using, perform the following:
$ which java /usr/local/packages/jdk1.1.6/bin/java $ which javac /usr/local/packages/jdk1.1.6/bin/javac $ java -version java version "1.1.6"
If JDK 1.1.6 does not appear within these commands, either put your JDK 1.1.6 installation at the start of PATH or remove the 1.1.3 installation. In addition, check your CLASSPATH for references to the incorrect JDK version.
After installing the JDK on your client, you must add the directory path to the following environment variables:
$JAVA_HOME
--must be set to the top directory of the installed JDK base
$PATH
--requires $JAVA_HOME/bin
$LD_LIBRARY_PATH
for Solaris or %LIB%
for Windows NT--must include$JAVA_HOME/lib
If your client is a Java client that interacts with a distributed application--CORBA, EJB, or RMI--you must perform one of the following before compiling your client code:
For the Java client to work across nodes in a distributed application, it must be compiled with appropriate server stubs. The required JAR or ZIP files that must be included in the client's CLASSPATH are as follows:
$ORACLE_HOME/lib/aurora_client.jar $ORACLE_HOME/lib/mts.jar $ORACLE_HOME/lib/vbjorb.jar $ORACLE_HOME/lib/vbjapp.jar
For a JDK 1.1 client to communicate with the Java 2 server, you must include the following JVM JAR file:
$JAVA_HOME/lib/classes.zip
For any interaction with JDBC, include the following ZIP file:
$ORACLE_HOME/jdbc/lib/classes111.zip
For any client that uses SSL, include the following JAR files:
$ORACLE_HOME/jlib/jssl-1_1.jar $ORACLE_HOME/jlib/javax-ssl-1_1.jar
For any client that uses Java Transaction API (JTA) functionality, include the following JAR file:
$ORACLE_HOME/jlib/jta.jar
For any client that uses JNDI functionality, include the following JAR file:
$ORACLE_HOME/jlib/jndi.jar
For a Java 2 client to communicate with the Java 2 server, you must make sure that one of the following JVM JAR files are in the CLASSPATH:
For any interaction with JDBC, include the following ZIP file:
$ORACLE_HOME/jdbc/lib/classes12.zip
For any client that uses SSL, include the following JAR files:
$ORACLE_HOME/jlib/jssl-1_2.jar $ORACLE_HOME/jlib/javax-ssl-1_2.jar
For any client that uses Java Transaction API (JTA) functionality, include the following JAR file:
$ORACLE_HOME/jlib/jta.jar
For any client that uses JNDI functionality, include the following JAR file:
$ORACLE_HOME/jlib/jndi.jar
If you are using the Accelerator for native compilation, include $JAVA_HOME/lib/tools.jar
$ORACLE_HOME/sqlj/lib/translator.zip
In addition to this file, add the appropriate runtime
X
.zip
file, as follows:
$ORACLE_HOME/sqlj/lib/runtime12.zip
$ORACLE_HOME/sqlj/lib/runtime12ee.zip
$ORACLE_HOME/sqlj/lib/runtime11.zip
$ORACLE_HOME/sqlj/lib/runtime.zip
$ORACLE_HOME/jsp/lib/ojsp.jar $ORACLE_HOME/lib/xmlparserv2.jar $ORACLE_HOME/lib/servlet.jar
If your JSP pages use OracleJML tags or database utility JavaBeans, add the following:
$ORACLE_HOME/rdbms/jlib/ojsputil.jar /*for JDK 1.1 use the xsu111.jar*/ $ORACLE_HOME/rdbms/jlib/xsu111.jar /*for JDK 1.2, use xsu12.jar*/ $ORACLE_HOME/rdbms/jlib/xsu12.jar
See the appropriate feature documentation for more information. You can also see examples of these JAR and ZIP files, used in both the README or Makefile, within the feature demo samples.
If you are compiling your server applications on your client node, you must include $ORACLE_HOME/lib/aurora.zip
in the CLASSPATH.
The port and SID for the listener are no longer configured within the database initialization file. Instead, the listeners are dynamically configured. This means, that you must use the Oracle Net lsnrctl
tool to determine the port and SID of a particular listener.
All examples provided within the $ORACLE_HOME/javavm/demo
directory use a service URL of "sess_iiop://localhost:2481:orcl
". You should modify this URL to contain your own hostname, and the port and SID of the listener. If you do not modify this URL, the samples will not work correctly. Specify a default URL as follows:
We provide a set of samples in the $ORACLE_HOME/javavm/demo
directory. These samples compile and run for a database installed with the Oracle JVM option. Execute these samples as a test of your installation.
$ORACLE_HOME/javavm/demo/examples/jsp/helloworld $ORACLE_HOME/javavm/demo/examples/corba/basic/helloworld $ORACLE_HOME/javavm/demo/examples/ejb/basic/helloworld
If these samples do not compile or run, your environment is incorrect. Similarly, if these samples compile and run, but your code does not, then a problem exists within your build environment or code.
Verify that the samples work before using more complex build environments, such as Visual Cafe, JDeveloper, or VisualAge.
|
Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|