| Oracle® Application Server Release Notes and New Features 10g Release 3 (10.1.3.4) Part Number E12523-04 |
|
|
View PDF |
This chapter describes issues and new features associated with Oracle Containers for J2EE. It includes the following topics:
Section 12.1, "Applications Share HTTP Client Static Memory"
Section 12.2, "JAZNMigration Tool Does Not Migrate ADFPrincipal Type Correctly"
Section 12.3, "Configuration Issues When Using an External LDAP Provider"
The HTTP Client library is loaded by the OC4J system class loader and is therefore inherited by all applications deployed in the OC4J instance. As a result, the HTTP Client's static memory is shared across all applications. An application that modifies default values that are stored in the HTTP Client's static memory may affect other applications that also rely on the HTTP Client library.The work around for this issue is to have each application import a local copy of the HTTP Client library. The HTTP Client's static memory is then private to the application and cannot be modified by another application.
The following example demonstrates how to configure an application to import a local copy of the HTTP Client library and not inherit the HTTP Client library loaded by the OC4J system class loader. The change must be made in an application's orion-application.xml file.
<orion-application>
...
<imported-shared-libraries>
<remove-inherited name="oracle.http.client">
</imported-shared-libraries>
...
<library path="ORACLE_HOME/j2ee/home/lib/http_client.jar"/>
...
</orion-application>
Be aware of the following issue when you use the OracleAS JAAS Provider migration tool to migrate policies from the file-based provider to the Oracle Identity Management (essentially, Oracle Internet Directory) security provider, either in policy mode or all mode: The migration tool prepends the Oracle Internet Directory realm name to custom or nonrealm principal names in grantee entries in the policy configuration. (A custom principal may come into play when authenticating through a custom login module, for example.)
In the migrated configuration, a custom principal name in a grantee entry becomes, for example, us/anyone instead of just anyone, assuming us is the realm name. This results in permission issues. For ADF applications, for example, this results in public pages not working after migration to Oracle Internet Directory as the security provider.
The following workarounds are available for this issue:
Manually remove the us/ prefix from the LDIF file that the migration tool creates, prior to importing it into Oracle Internet Directory.
Manually remove the us/ prefix from relevant grantee entries after the migration, using Oracle Internet Directory administration tools.
If you plan to use an external LDAP provider for an application, it is recommended that you use a middle tier installation that is configured with the default XML security provider.
If you have a middle tier installation that is associated with an infrastructure installation (such as OID) and you want to use an external LDAP provider, you need to manually edit the jazn.xml file. Change the provider and location attributes of the <jazn> element as follows:
<jazn provider="XML" location="./system-jazn-data.xml" ... >
When you replace JDK 1.5 with JDK 1.4.2, OC4J does not start and the OPMN log (ORACLE_HOME/opmn/logs//default_group~home~default_group~1.log ) gives an error similar to the following:
--------
Start process
--------
**************************** WARNING ******************************
You are currently running with data limits not set to unlimited.
You may experience out of memory(OOM) conditions.
In the event of an OOM error, please increase the data limit value.
You may use "ulimit -d unlimited" to set data limit as unlimited.
*******************************************************************
[ Unrecognized option:
-Xjit:exclude={oracle/sysman/emSDK/eml/util/iAS/IASLogConfig.getViewLogsURL(Ljav
ax/servlet/ServletContext;Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/
http/HttpServletResponse;)Ljava/lang/String;},
exclude={oracle/security/jazn/util/OHSH.update([B)V},
exclude={com/phaos/ASN1/ASN1Sequence.<init>(Ljava/io/InputStream;)V},
exclude={com/phaos/crypto/DES.l([B[IZ)V} ]
[ JVMCI123: Unable to parse 1.2 format supplied options - rc=-6 ]
Could not create JVM.
Use the following workaround to ensure that OC4J starts with JDK 1.4.2:
Remove the following lines from opmn.xml ($ORACLE_HOME/opmn/conf/opmn.xml):
-Xjit:exclude={oracle/sysman/emSDK/eml/util/iAS/IASLogConfig.getViewLogsURL(
Ljavax/servlet/ServletContext;Ljavax/servlet/http/HttpServletRequest;Ljavax/s
ervlet/http/HttpServletResponse;)Ljava/lang/String;},
exclude={oracle/security/jazn/util/OHSH.update([B)V},
exclude={com/phaos/ASN1/ASN1Sequence.<init>(Ljava/io/InputStream;)V},
exclude={com/phaos/crypto/DES.l([B[IZ)V}
Start the OC4J instance by using the following command:
opmnctl startall
When you replace JDK 1.5 with JDK 1.4.2, OC4J does not start and the OPMN log (ORACLE_HOME/opmn/logs//default_group~home~default_group~1.log ) gives an error similar to the following:
-------- Start process -------- Unrecognized VM option 'AppendRatio=3' Could not create the Java virtual machine.
Use the following workaround to ensure that OC4J starts with JDK 1.4.2:
Shut down the OC4J instance by using the following command:
opmnctl stopall
Remove the following lines from opmn.xml ($ORACLE_HOME/opmn/conf/opmn.xml):
AppendRatio=3
Start the OC4J instance by using the following command:
opmnctl startall
While using JDK 1.6 with Oracle Application Server 10g Release (10.1.3.4), JAZN Migration Tool fails.
Before running JAZN Migration Tool on JDK 1.6, you must set the environment variable, SHLIB_PATH, by using the following command:
export SHLIB_PATH=$ORACLE_HOME/jdk/jre/lib/PA_RISC2.0/jli
This section describes the new features for Oracle Containers for J2EE. This section includes the following topics:
The <session-tracking> element in orion-web.xml now includes the url-rewriting attribute to enable or disable URL rewriting. For example:
<session-tracking url-rewriting="false"/>
The default value of url-rewriting is true. When the value is set to false, URL rewriting is disabled.
URL rewriting is a technique for encoding a session ID into a URL. If Web clients do not support cookies and an application requires access to HTTP session data, you can enable URL rewriting instead of using cookies. For example, you can use URL rewriting for Wireless Application Protocol (WAP) clients, which do not support cookies.
To suppress the encoding of a session ID into a URL, you can set the url-rewriting attribute of <session-tracking> to false.
Data source proxy session support has been improved by allowing a managed data source's connection pool to automatically use proxy sessions. When proxy sessions are enabled, OC4J opens a proxy session on the connection for the application-authenticated user each time a connection request is made on the pool. The proxy session is then closed when the connection is returned to the pool.
Proxy session support includes proxy authentication, which is the ability to connect as a user through another user. For example, proxy authentication enables the middle tier to authenticate once to the database using a generic account and then establish a lightweight session on behalf of actual users. Proxy connections are obtained with the user associated with the current thread state at the time of the connection request.
To enable proxy connection support, add the proxy-sessions attribute (set to true) to the connection pool definition in data-sources.xml as demonstrated below. By default, proxy sessions are disabled.
<managed-data-source name="OracleDS"
connection-pool-name="Example Connection Pool"
jndi-name="jdbc/OracleDS"/>
<connection-pool name="Example Connection Pool"
max-connections="100"
min-connections="20"
num-cached-statements="10"
proxy-sessions="true">
<connection-factory factory-class="oracle.jdbc.pool.OracleDataSource"
user="user"
password="password"
url="jdbc:oracle:thin:@localhost:5521:main">
</connection-factory>
</connection-pool>
Proxy authentication requires that the application user exist in the database and be granted the proper CONNECT THROUGH privileges. The following SQL is used to setup a database to allow app_user to authenticate and connect as the user scott. The user scott must be defined for the connection pool, or managed data source in data-sources.xml.
ALTER USER app_user GRANT CONNECT THROUGH scott