| dev2dev Home > dev2dev WebLogic Server > e-docs WebLogic Server and WebLogic Express 8.1 Documentation > I18n in WebLogic Server (Internationalization) > I18n in WebLogic Server (Internationalization) |
I18n in WebLogic Server (Internationalization)
 
|
I18n in WebLogic Server (Internationalization)
The following sections describe the general notes on using WebLogic Server under Multibyte environment.
Overview of Internationalization
Main features of I18n in WebLogic Server:
You should understand how to specify appropriate encoding specific to Java and J2E before you build a distributed system that handles data with multi-byte characters using WebLogic Server. Moreover, you should control the encoding conversion with due regard for the encoding handling of the system (e.g. operating system, the Internet, backend system) connected to WebLogic Server.
The following is a concise description of the encoding handling in WebLogic Server.
WebLogic Server is a 100% pure Java application server program which uses Unicode for its internal encoding.
This allows WebLogic Server to handle characters of all languages at the same time, provided that their characters can be handled by Unicode.
The encoding conversion is needed when WebLogic Server exchanges character data with the outside.
In ordinary operating systems there is almost no environment working with Unicode, which is internal encoding of Java. Operating systems work with encoding called 'native encoding' which is defined individually for each platform. For example, the native encoding of the Windows system is a code page relevant to the language, the native encoding of the Unix system is encoding corresponding to the locale which is specified with the LANG environment variable, and the native encoding of a data base is a character set specified at the time of data base creation or the character set specified by the client.
Because of this situation, encoding conversion between native encoding and Unicode is needed when input and output is done in WebLogic Server. This encoding conversion always occurs when WebLogic Server exchanges character data with an operating system or an external resource
Note: Characters included in a serialized Java class stream are held as (UTF-8 encoded) Unicode in the internal information of the class. This means that you do not need to consider code conversion for serialized streams. For example, you do not need to consider encoding for EJB or RMI.
The encoding conversion process utilizes a large amount of CPU resource, because the conversion is done for individual characters. Avoiding code conversion is good practice in the designing of an application to ensure better system performance.
Separation between the Encoding Conversion for the Server Itself and the Encoding Conversion for Application Components and Resources on WebLogic Server
In WebLogic Server, the encoding conversion for the server itself and the encoding conversion for application components and resources on WebLogic Server are separate.
In WebLogic Server, the encoding of the server log or the Administration Console is determined by the default encoding of a server's Java VM or a browser's language setting independently of the encoding of the application component or the language of the content that the WebLogic Server is serving.
Moreover, you can configure the WebLogic Server's behavior independently of the locale or the language on which the WebLogic Server is working.
Also, you can set the encoding conversion individually for each resource configured on the WebLogic Server's container (ex. JDBC Conection Pool).
The encoding conversion of WebLogic Server itself includes:
The encoding conversion of individual applications includes:
Resources on WebLogic Server include:
When you specify the encoding on WebLogic Server, you need to make clear for which categories you are specified the encoding. Then you need to check if a valid Character object can be created and if a Character object in WebLogic Server can be properly converted to the intended encoding.
As indicated above, you should understand the behavior of the encoding conversion for appropriate setting. If you do not specify the encoding conversion, applications may not handle multi-byte characters properly.
If you do not specify the encoding, the default encoding appropriate for the situation is used. The default encoding may vary according to the target's specification or the environment.
Example of the Default Encoding
The default encoding which affects the behavior of the WebLogic Server includes:
Because different default encoding is used for different targets, as indicated above, WebLogic Server cannot handle Multibyte properly if you do not specify the appropriate encoding. You should understand following sections to be able to control the encoding conversion.
The encoding means the "character set" in Java language terminology. There are a number of words that describe a character set, but the definition of each word is slightly different.
The encoding or the character set means the definition which assigns computer-readable codes to the set of characters of a specific language so that the computer can deal with these characters. This definition is called "encoding" in the Java terminology, "character set" in the Internet terminology.
Java language absorbs these differences in its I/O section, so that it handles all character as Unicode inside it. This means that Java can handle any character set as long as the encoding definition for the character set exists, and can absorb any encoding differences existing between various systems. However, there is no encoding conversion table that handles all minor differences of all existing encodings at the present time. Also, there are some limitations on the existing encoding table that result from the problem of consistency with Unicode.
In Java Web application servers, the difference between the Java encoding name and the MIME character set is especially important. The MIME character set is defined by IANA, which is used on the Internet and in a XML files. WebLogic Server uses a mapping table which associates the Java encoding name and the IANA character set name to absorb this difference. Using this table, WebLogic Server can handle a file defined as 'Shift_JIS' on JSP or as 'MS932' with the Java encoding name. You can modify the mapping table of WebLogic Server to handle the 'Shift_JIS' character set as 'cp943' Java encoding.
Xerces is a built-in XML parser of the WebLogic Server, and it has its own IANA-to-Java mapping table. The user cannot customize this mapping. For example, the IANA charset name of 'Shift_JIS' is mapped to the Java encoding name of 'SJIS'.
Basically, in WebLogic Server, use a Java encoding name to specify encoding. In J2EE, Internet or XML, use the IANA character set name. You can modify this mapping as necessary.
WebLogic Server provides Japanese-language, Korean-language, Chinese-language and English-language version installers. The English-language, Korean-language and Chinese language installers can be downloaded from the BEA Systems, Inc. (USA) Website. The Japanese-language version installer can be downloaded from the BEA Japan web site.
The following are the differences between the Japanese-language, Korean-language, Chinese-language and English-language version installers. In all four installers, the program files that affect the behavior of WebLogic Server are the same, so they can be regarded as the same software. In addition, you will have no problem with interoperability between the WebLogic Server installed using the English-version installer and that installed using the Japanese-language, Korean-language or Chinese-language version installers.
In the WebLogic Server 8.1 Japanese-language, Korean-languae and Chinese-language versions, the following features are not available:
WebLogic Server System Administration
The following items work with the JVM default encoding for the WebLogic Server:
The following item works with the default language of the browser:
To change the encoding for log output, etc., working with the server default encoding, use the following procedure:
Encoding in WebLogic Server and the Java Virtual Machine
In WebLogic Server, you can set the encoding with various scopes. For example, you can set the ContentType/Charset to specify the encoding that WebLogic Server outputs to a client. Also, you can use the weblogic.codeset property to specify the encoding for a JDBC connection when using WebLogic jDriver. These and many other features are discussed in this document. Note that there is no relationship between the encoding that you specify for a particular scope and the default encoding for the Java VM on which WebLogic Server runs. If the Java VM is running in the English locale, there is no problem in providing services that use JSP files that include multibyte characters. However, the handling of the following strings is dependent on the Java VM default encoding:
These strings work with the Java VM default encoding for each platform (the encoding specified by the file.encoding Java system property). For example, the language and encoding of log messages which WebLogic Server outputs to a terminal console are dependent on the encoding specified in the Java VM. The file.encoding java system property is based on the platform environment and the system locale. If you want to switch the language and encoding of the WebLogic Server log messages, you need to switch the system locale accordingly. You cannot switch the Java VM default encoding dynamically once the VM has been started. Make sure of the following settings before you restart WebLogic Server.
From the Regional Options tab in the Regional and Language Options Control Panel icon, select "English (United States)", "Japanese", "Korean", "Chinese (PRC)", "Chinese (Taiwan)", etc. This allows the server to use CP1252 or MS932, MS949, GBK, MS950 as the default encoding.
Specify the locale supported by your platform in the LANG environment variable.
Below are the settings of the server encoding and the LANG environment variable:
Table 2-1 Settings of the server encoding and the LANG environment variable
For example, if you specify EUCJIS on Solaris, the LANG setting looks like this:
LANG=ja
How to Check the Server Encoding
The Java VM default encoding becomes the WebLogic Server default encoding. You can check the encoding by referring to the log messages from the Administration Console. The following are the steps:
Notes on Configuring Administration and Managed Servers
Use the same encoding for all the WebLogic Servers through out the domain.
In WebLogic Server, it is neccesary to have the same encoding settings for all the servers in the domain.
For example, when a Windows platform exists within the domain, standardize with Shift_JIS encoding types such as MS932. In the case of a server with different encoding, that servers's log will not show correctly.
Use the same encoding for all the WebLogic Servers in a cluster.
In WebLogic Server, it is neccesary to have the same encoding settings for all the servers in the cluster.
For example, when a Windows platform exists within the cluster, standardize with Shift_JIS encoding types such as MS932. In the case of a server with different encoding, that servers's log will not show correctly.
The config.xml file is input/output in UTF-8. When editing the file directly with a text editor, read and save in utf-8.
Note on Using the WebLogic Server as a Web Server
The following is a note on using the WebLogic Server as a Web server:
To add the contentType charset parameter to the HTTP header for serving HTML files, insert the following definition in the web.xml file, which can explicitly specify the encoding for HTML files:
<mime-mapping>
<extension>html</extension>
<mime-type>text/html;charset=Shift_JIS</mime-type>
</mime-mapping>
This allows you to omit the charset setting in the HTML file by using a META tag such as:
<META HTTP-EQUIV="content-type" CONTENT="text/html; charset=Shift_JIS">
When creating a JDBC connection pool, you must specify the appropriate encoding for a connection to the DB which uses multi-byte characters. You may need to match the encoding conversion mapping between the Web layer and the DB layer.
For more information, see "Codeset Support" of the "WebLogic jDriver Advanced Features" chapter in "WebLogic jDriver for Oracle (Deprecated)".
In WebLogic Server, the encoding for multi-byte characters in the DD file of the J2EE component is handled as specified in the XML declaration. If the DD file has no encoding attribute in the XML declaration or has no XML declaration, the file is handled as UTF-8.
When you edit the DD file and save changes in WebLogic Builder or Administration Console, the encoding of the file is kept as in the original file.
DD files created in WebLogic Builder or Administration Console have no XML declaration. When you change the encoding of such a file, set the encoding attribute in the XML declaration and the encoding conversion for the file appropriately.
Notes on Using Administration Console
The Language at Administration Console's Startup
The language displayed when the Administration Console first starts is the preference language specified in your Web browser. For example, if you are using the Japanese version of Windows and Internet Explorer, the Administration Console will be displayed in Japanese when it first starts. If you want to change the language first displayed to English, you can change it by setting the preference language in your browser to English.
The languages you can select for the Administration Console in WebLogic Server 8.1
Select encoding according to the encoding for the Administration Server to which the Administration Console is connected.
Switching the Language after Administration Console Startup
Select the desired language from the Language drop-down list on the Preferences page on the Console's home page.
Notes on Using Servlets and JSPs
Encoding Conversion, Standards, Scope and Preference
WebLogic Server is a Java application program. All strings are handled internally as Unicode strings. On the other hand, various charsets are used for HTML pages on HTTP protocol. In WebLogic Server, the encoding conversion between Unicode and the HTML charsets is performed by using the Java encoding converter when handling HTML data. Therefore, when using Weblogic server, how to handle the conversion in an application between Unicode strings internally handled in the server and HTML encoding is important.
In WebLogic Server, there are several parameters for setting encoding based on specific scopes, and using these paramaters for the application you use can successfully deal with the problem.
Also, in WebLogic Server, it is possible to set encoding for each module you use, independently of the JavaVM default encoding.
In WebLogic Server, some of the ways that you set the encoding are defined by the J2EE specification. Others are WebLogic proprietary specifications. You need not specify all of them. Read the following description and combine the most appropriate encoding settings for your environment.
The encoding settings related to JSP/Servlet include:(
Basically, the more specific definition of scope will take priority. For example, if Shift_JIS is set as the default encoding for the JSP container, and EUC-JP is specified in the page tag of a specific JSP, then the encoding specified in the page tag will take priority (i.e. EUC-JP will be used).
It is recommended that you use the same particular encoding throughout your application
A general ouline for using multibyte language
Regarding the following, note that if you do not specify any encoding for HTTP request and HTTP response then ISO-8859-1 encoding will be used.
The following sections give details of each setting of Servlet and JSP.
Specifying the Encoding for an HTTP Response --- response.setContentType()
To specify the encoding for an HTML page generated by a Servlet, use the setContentType() method. The call to setContentType() specifies the following:
Therefore, you must call the setContentType() before getting a writer.
res.setContentType("text/html;charset=Shift_JIS");
PrintWriter out = res.getWriter();
This call specifies the contentType in the HTTP header. This means that the encoding for your browser display is also specified.
Specifying the Encoding for an HTTP Request --- request.setCharacterEncoding or <input-charset>
Now you have finished the setting of the encoding for an HTTP response which is data sent from WebLogic Server to a client using the above. The following describes how to set the encoding for an HTTP request when sending data from a client to WebLogic Server.
There are three ways to specify the encoding for an HTTP request:
This method is most compliant with the HTTP specification. However, you cannot specify the value in a Microsoft Internet Explorer or Netscape browser.
Use the request.setCharacterEncoding() method. You can specify the encoding for each request. Also, you can perform delicate operations such as controlling the encoding dynamically. In addition, the setCharacterEncoding() is compliant with the Servlet 2.3 specification. Therefore, you can obtain application portability.
request.setCharacterEncoding("Shift_JIS");
String pval = request.getParameter(pname);
In WebLogic Server 6.1 or later versions, this is set in weblogic.xml. However, in WebLogic Server 6.0 it is set in web.xml. Also, the element names, etc., are changed. Therefore, in the case of migrating from WebLogic Server 6.0, the weblogic.xml and web.xml files will require modification. Please refer to the migration guide.
To specify <input-charset>, for example, you can set it so that encoding for request URLs is obtained as follows:
Write the <input-charset> for the target Web application in the deployment descriptor (weblogic.xml) as shown below.
In the <charset-param> (which is embedded in the <weblogic-web-app> ), write the request URL path for which you want to specify the encoding and the encoding which you want to specify for the HTTP request in the IANA name.
For information about mapping between a Java encoding name and an IANA character set, see the “Mapping Between a Java Encoding and an IANA Character Set (Setting in weblogic.xml)” section.
Below is an example of a single web-app that handles multiple encodings.
In the example below, the encoding for "/*" is set to Shift_JIS and the encoding for "/rus/joe/*" is set to ISO-8859-1.
<charset-params>
<input-charset>
<resource-path>/*</resource-path>
<java-charset-name> Shift_JIS</java-charset-name>
</input-charset>
</charset-params>
<charset-params>
<input-charset>
<resource-path>/rus/joe/*</resource-path>
<java-charset-name>ISO-8859-1</java-charset-name>
</input-charset>
</charset-params>
For more information about this setting, see "charset-params" in "Developing Web Applications for WebLogic Server".
Specifying the Encoding for a JSP File --- pageEncoding (Optional)
To specify the encoding which the WebLogic Server JSP container or JSP compiler uses to read a JSP file, specify the pageEncoding directive in the page tag as follows:
<%@ page contentType="text/html; charset=Shift_JIS" pageEncoding="Shift_JIS" %>
Specifying the Encoding for Page Output --- contentType Directive in the page Tag
To specify the encoding for page output, specify the contentType directive in the page tag as follows:
<%@ page contentType="text/html; charset=Shift_JIS" %>
In addition, when you specify the contentType in the page directive, the same contentType is specified in the HTTP header for HTTP response. This means that the encoding for your browser display is also specified.
When the pageEncoding directive is not set, the contentType directive is used for the encoding for reading a JSP file.
If the JSP container finds the content type setting, it will stop parsing the JSP file, switch the file reader to this new-specified encoding, and parse the JSP page from the beginning again. If more than one contentType is specified in one file, a parsing error occurs. Therefore, when you include a file in another one using static include, if both files have their own encoding specification, an error occurs. In dynamic include, an error will not occur but garbled characters will be generated.
Note: Even if more than one contentType is specified in one file, a parsing error can be suppressed, provided that each specifies the same encoding (See the "Static vs. Dynamic Includes, Encoding Differences" section).
<jsp-param>
<param-name>backwardCompatible</param-name>
<param-value>true</param-value>
</jsp-param>
For example, if an 'include origin' and an 'include destination' both have their own page directive when you include using static include (<%@ include), and the single translation unit has multiple page directives, you will have no trouble, provided that each page directive specifies the same encoding.
Specifying the Encoding for an HTTP Request
You can specify the encoding for an HTTP request in a JSP the same way as in a Servlet.?See the "For Servlets" section.
<%
request.setCharacterEncoding("Shift_JIS");
String pval = request.getParameter(pname);
%>request.setCharacterEncoding or <input-charset>
Mapping Between a Java Encoding and an IANA Character Set (Setting in weblogic.xml)
When you specify the encoding using the setContentType() method or the contentType directive in the page tag, use an IANA character set name. However, when you handle the encodings in WebLogic Server, which is a Java application, these values must be Java encoding names. WebLogic Server has the default mappings internally also and normally uses them. The default mappings also include mappings which are not defined in IANA, but are conventionally used in the Content-Type for HTML (See MIME-Java Encoding Mapping Table Defined in WebLogic Server).
Example: x-sjis ----> Shift_JIS
You can change this mapping in your own right. Set the mapping in the web application deployment descriptor as follows.
For example, 'Shift_JIS' setting in the contentType is handled as SJIS in WebLogic Server, because the IANA character set 'Shift_JIS' is mapped to the Java encoding 'Shift_JIS' (Shift_JIS is used as an alias for SJIS in JDK1.4).
Note: In Java 1.3, the IANA character set Shift_JIS is handled as MS932 (From JDK 1.1.8 to JDK 1.4.0, Shift_JIS is handled as SJIS in JDK1.4.1 or later).
Consequently, MS932-specific characters cannot be used when Shift_JIS is used as the default setting.
You can overwrite the default mappings by defining the <charset-mapping> in weblogic.xml.
In the example below, Shift_JIS is mapped to MS932.
<charset-params>
<charset-mapping>
<iana-charset-name>Shift_JIS</iana-charset-name>
<java-charset-name>MS932</java-charset-name>
</charset-mapping>
</charset-params>
Note that this setting is not compliant with J2EE. It was set in the web.xml in WebLogic Server 6.0. In WebLogic Server 6.1 or later, it has been changed to be set in the web application deployment descriptor weblogic.xml. Also, the element names, etc., are changed. Note these changes in the case of migrating from WebLogic Server 6.0.
Workaround to Encode an HTTP Request with ISO-8859 encoding
If iso-8859 is specified as the encoding for an HTTP request in the <input-charset>, you can still obtain an HTTP request with a different encoding by using the following workaround.
new String(request.getParameter(itemQ[i]).getBytes ("8859_1"), "SJIS")
However, an HTTP client whose contentType in the HTTP header for HTTP request is specified as follows cannot use this workaround, because the encoding specified in the contentType in the HTTP header will take priority over that specified in the <input-charset>. In this case you must modify the application code.
Content-Type: application/x-www-form-urlencoded;charset=shift_jis
Static vs. Dynamic Includes, Encoding Differences
<%@ include file="relativeURL" %>
In this case, all the include files are loaded and gathered together in one file before JSP compile is performed, and therefore if the encoding is specified in the file that does the including, the included file will be handled as a file using the same encoding as the include file, even though it is not specified its encoding. In WebLogic Server 6.1 or earlier, a compiling error does not occur if an 'include origin' and an 'include destination' both have the same encoding specifications. In WebLogic Server 8.1, a compiling error will occur if both have their own page directive. To avoid this, set the 'backwardCompatible' in weblogic.xml to true.
JSP compiling error occurs if the encoding settings are different between the 'include origin' and the 'include destination'.
<jsp:include page="{ relativeURL | <%= expression %>}" flush="true" />
With dynamic includes, the page is not included when it is loaded, and left in the tag state. The page will be included when the JSP is executed. Therefore, the encoding set in the JSP that does the including will not apply to the included file(s).
Hence, you must also specify the encoding in the included file.
When migrating a CGI service which uses multi-byte characters to a CGI servlet on the WebLogic Server, you must specify the appropriate contentType charset parameter in the HTTP header generated by the CGI program. If the contentType is not set, ISO-8859-1 is used, this being the default encoding for the J2EE Servlet container.
You must also use the appropriate in order to receive input strings from a client correctly. You need to write it in the DD file of the target Web application. If it is not set, ISO-8859-1 is used.
Handling of SOAP Messages and its Encoding
In the WebLogic Server Web service, encoding handling is compliant with the SOAP1.1 and SOAP1.2 specification (*Note 1). HTTP/SOAP messages based on the SOAP1.1 specification have text/xml media type, and the encoding for these messages is handled according to RFC2376. HTTP/SOAP messages based on the SOAP 1.2 specification have application/soap+xml media type, and the encoding for these messages is handled according to RFC3023. The following are behaviors based on the RFC specification:
WebLogic Workshop also acts according to this specification as well as WebLogic Sever 8.1. Therefore, make sure that the contentType charset is specified correctly for the client which calls the Web service(s) developed by WebLogic Workshop using HTTP/SOAP.
For WebLogic Server, HTTP/SOAP messages are generated with utf-8 as the default. At the time of generation, 'encoding=UTF-8' is added to the SOAP message's ContentType header.
Note: When you start the WebLogic Server on the English locale (e.g. LANG=C is specified on UNIX), only us-ascii characters can be used in SOAP messages. Other characters are not supported. When multibyte characters are used in the Web service(s), make sure that you start the WebLogic Server in the appropriate locale.
If you want to use characters other than us-ascii on the WebLogic Server started in the English locale, set the following startup option in the WebLogic Server startup script file. This generates messages in utf-8, even if the WebLogic Server is running on the English locale.
Note: We recommend using UFT-8 for SOAP messages.
-Iweblogic.webservice.i18n.charset=utf-8
Web Services Home Page is generated in the server VM default encoding.
UDDI Explorer supports only us-ascii characters, and cannot use multi-byte characters properly.
XML -- Multi-byte Characters Handling in StreamParser
Use the ElementFactory class' createStartDocument() as shown below in order to add encoding information to the XML header generated using the XML Streaming API.
XMLOutputStreamFactory factory = XMLOutputStreamFactory.newInstance();
XMLOutputStream output = factory.newOutputStream(new
OutputStreamWriter(new FileOutputStream(fname),"Shift_JIS"));
output.add(ElementFactory.createStartDocument("Shift_JIS","1.0"));
output.flush();
The followings are notes on parsing an XML document containing multibyte characters using XML Streaming API. The main points are the same as in the notes on using the Xerces parser.
Use a bytestream when using a stream in the parser input. This enables XML encoding auto-detection of the parser, so that the parser can generate a character stream using the encoding specified by the encoding attribute in the XML declaration, thus ensuring appropriate parsing.
When passing as a Unicode character stream, the parser ignores the xml header's encoding specification. In this case, take caution on the user side to pass the correct character stream.
Using BEA WebLogic Type4 Oracle Driver
In WebLogic Server8.1, BEA Weblogic Type4 Drivers for each kind of database (e.g. Oracle, SQL Server, DB2. etc.) are installed. The following is an explanation of creating an environment using WebLogic Type4 Driver for Oracle as an example:
In WebLogic Server8.1, the BEA WebLogic Type4 driver is installed in the WL_HOME\server\lib directory. These files are contained in weblogic.jar's manifest classpath and automatically added to the server classpath.
Thus, using WebLogic Type 4 drivers, you can directly connect to a database from JDBC client (JSP, Servlet, etc.) on WebLogic Server. For more information about programming for JDBC client used in WebLogic Type4 driver, see WebLogic Type 4 JDBC Drivers.
Setting a connection pool from the administration console
When configuring the connection pool which uses BEA WebLogic Type4 Oracle driver, please make the following settings:
For details, see WebLogic Type 4 JDBC Drivers.
Setting a connection pool from the administration console
When setting a connection pool during domain creation in Configuration Wizard
Vendor : Oracle
Driver : BEA's Oracle Driver(Type 4) Version 8.1.7,9.0.1,9.2.0
(please set all other items to match your environment)
When setting a connection pool manually
Add the following to config.xm of the domain where you create the connection pool: (change the value in the underlined portion to match your environment)
<JDBCConnectionPool DriverName=weblogic.jdbc.oracle.OracleDriver"
Name="testpool"
Password="tiger"
Properties="user=scott;portNumber=1521;SID=testdb;serverName=testserver"
Targets="myserver"
TestTableName="SQL SELECT 1 FROM DUAL"
URL="jdbc:bea:oracle://jpw2k17:1521"/>
Using BEA WebLogic jDriver for Oracle
Here is an explanation of environment settings for BEA WebLogic jDriver for Oracle:
WebLogic OCI driver native library is neccessary to use the BEA WebLogic jDriver for Oracle driver. For 32bit Windows, WebLogic OCI driver native library is installed in WL_HOME\server\bin\. For Unix Platform, WebLogic OCI driver native library is installed in WL_HOME/server/lib/{OS name}/.
In WebLogic Server8.1, the library for 9.2.0 is the default. To reference different library versions in the Windows environment, add the desired library path in PATH. To reference different library versions for UNIX environment, add the desired library path in LD_LIBRARY_PATH (For HP-UX, SHLIB_PATH).
In addition to WebLogic OCI Driver native library settings, the following settings are necesary in order to use JDriver for Oracle:
set PATH=%ORACLE_HOME%\bin;%PATH% In Unix environment, add D_LIBRARY_PATH or SHLIB_PATH to lib ( or lib32). export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH=$ORACLE_HOME/lib32:$LD_LIBRARY_PATHFor more information, see Setting Up the Environment for Using WebLogic jDriver for Oracle
Please complete the following settings to configure a connection pool using WebLogic jDriver for Oracle. For more information, please see Setting Up a Connection Pool in Configuring WebLogic jDriver for Oracle.
Setting a connection pool from the administration console
When setting a connection pool during domain creation in Configuration Wizard
Vendor : Oracle
Driver : Oracle's Driver(Type 2) Version 8.1.7,9.0.1,9.2.0
(please set all other items to match your environment)
When setting a connection pool manually
Add the following to config.xm of the domain where you create the connection pool: (change the value in the underlined portion to match your environment)
<JDBCConnectionPool DriverName=weblogic.jdbc.oci.Driver"
Name="testpool"
Password="tiger"
Properties="user=scott;server=testdb.testserver"
Targets="myserver"
TestTableName="SQL SELECT 1 FROM DUAL"
URL="jdbc:weblogic:oracle"/>
Here is an explanation of setting up the environment for using Oracle OCI driver:
In the domain using Oracle OCI driver, set startWebLogic.cmd (or startWebLogic.sh) as follows:
%ORACLE_HOME% represents the install directory of the Oracle Client.
%ORACLE_HOME%\jdbc\lib\classes12.zip
%ORACLE_HOME%\jdbc\lib\nls_charset12.zip
%ORACLE_HOME%
Now, using Oracle OCI driver, you can directly connect to a database from JDBC client (JSP, Servlet, etc.) on WebLogic Server. For more information about programing for JDBC client with Oracle OCI driver, see the Oracle manual.
When setting a connection pool using Oracle OCI driver, please make the following settings:
Setting a connection pool from the administration console
*Add the following to the CLASSPATH:
%ORACLE_HOME%\jdbc\lib\classes12.zip
%ORACLE_HOME%\jdbc\lib\nls_charset12.zip
*Add the following to the PATH:
%ORACLE_HOME%
Please change "URL" as shown above when using Oracle Client 8.
<Before Modification> jdbc:oracle:oci:@[database name].[database server name]
<After Modification> jdbc:oracle:oci8:@[database name].[database server name]
When setting a connection pool during domain creation in Configuration Wizard
Vendor : Oracle
Driver : Oracle's Driver(OCI) Version 8.1.7,9.0.1,9.2.0
(please set all other items to match your environment)
*Add the following to the CLASSPATH:
%ORACLE_HOME%\jdbc\lib\classes12.zip
%ORACLE_HOME%\jdbc\lib\nls_charset12.zip
*Add the following to the PATH:
%ORACLE_HOME%
<Before Modification> URL="jdbc:oracle:oci:@[database name].[database server name] <After Modification> URL="jdbc:oracle:oci8:@[database name].[database server name]
When setting a connection pool manually
*Add the following to the CLASSPATH:
%ORACLE_HOME%\jdbc\lib\classes12.zip
%ORACLE_HOME%\jdbc\lib\nls_charset12.zip
*Add the following to the PATH:
%ORACLE_HOME%
(change the value in the underlined portion to match your environment)
<JDBCConnectionPool DriverName=oracle.jdbc.driver.OracleDriver"
Name="testpool"
Password="tiger"
Properties="user=scott"
Targets="myserver"
TestTableName="SQL SELECT 1 FROM DUAL"
URL="jdbc:oracle:oci:@testdb.testserver"/>
State URL as shown below when using Oracle Client version 8.
URL="jdbc:oracle:oci8:@testdb.testserver"
Oracle Thin driver version 9.2.0 is installed with WebLogic Server8.1. How to set up the Orcale Thin driver is explained below.
In WebLogic Server8.1, Oracle Thin version 9.2.0 is installed in the WL_HOME\server\lib directory. This file is contained in weblogic.jar's manifest classpath and is added automatically to the server classpath. Accordingly, you can connect directly to a databse from a JDBC client (JSP, Servlet, etc.) on WebLogic Server by using Oracle Thin driver.
For more details and infomation about using other versions of Oracle Thin driver, see Using Third-Party Drivers with WebLogic Server in Programming WebLogic JDBC.
For information about programming for JDBC client using Oracle thin driver, see Oracle manual.
character set support by nls_charset12.zip
Oracle Thin driver supports US7ASCII,WE8DEC,ISO-LATIN-1,UTF-8 chracter sets in CHAR and VARCHAR types. Add nls_charset12.zip to the CLASSPATH when using other character sets. nls_charset12.zip will be installed in WL_HOME\ext\lib.
Add WL_HOME\ext\jdbc\oracle\920\nls_charset12.zip in the CLASSPATH of the startWebLogic.cmd (or startWebLogic.sh) of the domain you use. For more information, see Using the Oracle Thin Driver.
Connection Pool Setup
When configuring the connection pool using Oracle Thin driver, setup as follows. For more detailed information, see Configuring and Using Connection Pools in Programming WebLogic JDBC.
Setting a connection pool from the administration console
a) Configure a domain.
b) Open "Configure a new JDBC Connection Pool" using the "Service" > "JDBC" > "Connection Pools" tab in the administration console.
c) In the "Choose Database" screen, select "Oracle" for Database type and select "Oracle`s Driver (Thin)
Version8.1.7,9.0.1,9.2.0" for database driver.
d) In the next screen, set the name and properties of the connection pool.
e) Test the driver configuration in the "Test database connection" screen.
f) After sucessful connection, execute "Create and Deploy" in the next screen.
When setting a connection pool during domain creation in Configuration Wizard
a) Start-up Configuration Wizard
b) Choose an optional template and select a custom configuration.
c) Select "Yes" in the "Database(JDBC)option" screen.
d) Make the following settings in the "Configure a JDBC Connection Pool" screen:
Vendor : Oracle
Driver : Oracle's Driver(Thin) Version 8.1.7,9.0.1,9.2.0
(please set all other items to match your environment)
When setting a connection pool manually
Add the following to config.xm of the domain where you create the connection pool:
(change the value in the underlined portion to match your environment)
<JDBCConnectionPool DriverName="oracle.jdbc.driver.OracleDriver"
Name="testpool"
Password="tiger"
Properties="user=scott"
Targets="myserver"
TestTableName="SQL SELECT 1 FROM DUAL"
URL="jdbc:oracle:thin:@testserver:1521:testdb/">
Limitations when Connecting Simultaneously to Databases of which the Encodings are Different
When using the OCI driver, you must specify the same encoding for the NLS_LANG and the weblogic.codeset. If these parameters are set to the same value, the encoding conversion will be performed on the Oracle side because you are connected to the Oracle side as a client which has a particular NLS_LANG.
For example, if both the encodings for the NLS_LANG and the weblogic.codeset are SJIS, the appropriate encoding conversion will be performed on the Oracle side, even though the encoding for the Oracle DB is EUC-JP. If the two parameters are the same, the connection will be made successfully regardless of the DB's encoding.
Notes on Encoding Conversion Using DB
If you do not use the same converter for the conversion between the platform native encoding and the Java encoding, the characters may be handled incorrectly. This problem is caused by the definition of Unicode and JIS.
For example, if you use the following converters on the encoding conversion between the platform native and Java..
DB -------------> WebLogic Server -------------> Web Browser
SJIS Windows-31J
The following codes cannot be handled correctly:
In this case, you must use SJIS exclusively for the output from WebLogic Server to the Web browser. For example, if the following encoding is specified in the page tag in JSP:
<%@ page contentType="text/html; charset=Windows-31J" %>
this 'Windows-31J' setting must be changed to 'Shift_JIS' to be converted from Unicode to the native platform.
Therefore, in this case you must write the definition as follows in the deployment descriptor (weblogic.xml) for the Web application to change the default encoding mapping table that WebLogic Server has internally.
<charset-params>
<charset-mapping>
<iana-charset-name>Shift_JIS</iana-charset-name>
<java-charset-name>SJIS</java-charset-name>
</charset-mapping>
</charset-params>
Java's MS932 encoding table supports conversion to an external characters area. By using MS932, you can provide content using iMode external characters.
Japanese Code Examples in and below the src_ja Directory Need to be Built in SJIS Locale (Japanese-language version only)
WebLogic Server 8.1 provides Japanese code examples in Shift_JIS. Therefore, to build them set up your shell environment which runs the ant build script in Shift_JIS.
 |
 |
 |
