1. Migrate JCS - SaaS Extension apps to WebLogic Server on Oracle Cloud Infrastructure
  2. Update and Validate Your Java Applications

Update and Validate Your Java Applications

The following are the high-level steps for preparing a Java EE app currently running on Oracle Java Cloud Service - SaaS Extension, to run on Oracle WebLogic Server for OCI.

Take note of the following application environment changes. You will need to update your application code to account for the different compatible versions between the two environments. For details of the differences in each product version, see the product documentation.

Area Oracle Java Cloud Service - SaaS Extension Oracle WebLogic Server for OCI
Oracle Java Standard Edition JDK 7 JDK 8
Oracle Java Enterprise Edition Java EE 5 Java EE 7
Oracle WebLogic Server WebLogic Server 11g (10.3.6) WebLogic Server 12c
Oracle Fusion Middleware Oracle Fusion Middleware 11g Release 1 (11.1.1.7.1 or 11.1.1.9.1) Oracle Fusion Middleware 12c Release 2 (12.2.1.x)
Oracle JDeveloper Oracle JDeveloper 11g Oracle JDeveloper 12c

Note that upgrading your Oracle WebLogic Server includes upgrading WebLogic (Java EE) web services (JAX-RS and JAX-WS).

Perform Required Update and Validation Steps

Re-factor and then test your Java applications for the new environment.

Each of the following steps highlights at a high level a process you need to perform to update and validate your applications.

  1. Identify secured and anonymous pages in your existing application. Usually application pages are secured using the CLIENT-CERT configuration in web.xml.
  2. Identify roles used in the current application. ADF applications use the jazn-data.xml file to define roles, while Java EE applications may specify application roles and security constraints within the application deployment descriptors in the web.xml file, or in the application code.
  3. Identify the policies used for web services security for your existing applications.
    Client security policies for SOAP client applications are located in the application code, and typically include
    • oracle/wss11_saml_token_with_message_protection_client_policy
    • oracle/wss_saml_token_bearer_over_ssl_client_policy
    The default policy for REST client applications is oracle/http_saml20_token_bearer_over_ssl_client_policy
  4. Identify whether or how the application is integrated with the Fusion-based Oracle Application.
    Common patterns include:
    • Embedding page or links using Application Composer, Page Integration, or Page Composer tooling
    • Springboard by using the Structure tool
    • Navigation by using Navigator configuration
  5. Identify application dependencies.
    For example, identify any of the following dependencies:
    • Libraries
    • SSL certificates
    • Web Services Security certificates
    • System properties
    • Filesystem structure expected by the application
    • Credentials entries in the OPSS Credential Store
    • Email notification usage
  6. Export data from Database Schema and import into the new database service on Oracle Cloud Infrastructure. Note that for Oracle Cloud Infrastructure Database Systems, you will need to install Oracle Application Express (APEX) and migrate applications.
    See the Oracle Database Cloud - Database Schema Service documentation for details.
  7. Configure web-tier security using Oracle Identity Cloud Service to update protected application resources, as described in the Oracle WebLogic Server for OCI documentation.
  8. Configure role authorization. Integrate OPSS user and group APIs with Oracle Identity Cloud Service, as described in the Oracle WebLogic Server for OCI documentation.
  9. Download and install Oracle JDeveloper 12c. This version is aligned with the Oracle WebLogic Server version selected earlier.
  10. Open your existing Java EE applications in Oracle JDeveloper 12c. JDeveloper will automatically migrate the project to 12c, including ADF dependencies. Check the Oracle JDeveloper documentation for details.
  11. Deploy and validate your application to Oracle WebLogic Server for OCI:
    1. Generate your WAR or EAR file from Oracle JDeveloper.
    2. Log in to the Oracle WebLogic Server Administration Console.
    3. Deploy your WAR or EAR file to the cluster or managed servers of the WebLogic Domain.
  12. For page integrations, update application URLs in your Oracle Fusion-based applications by using Application Composer or Page Composer, as appropriate for the specific application.
  13. Validate your application by performing testing on test or development environments.
    Note that you may need to configure web-tier security and role authorization before you can complete application validation, as described in the next article.
Configure web-tier security and role authorization in Oracle Identity Cloud Service as described in the next article before you deploy your application to your production environment.

Diagnose and Resolve Permissions Issues

You may find that some of your Java application code throws AccessControlException errors in the new environment. You can diagnose and resolve these permission issues by checking logs for details and then configuring permission grants using Oracle Enterprise Manager Fusion Middleware Control.

When defining the codeBase to grant permissions (in step 2 of the following procedure), the following environment variables may be helpful:

  • oracle.deployed.app.dir=/u01/data/domains/wls_domain/servers/wls_adminserver/tmp/_WL_user
  • oracle.deployed.app.ext=/-
  • common.components.home=/u01/app/oracle/middleware/oracle_common
  • domain.home=/u01/data/domains/wls_domain

To diagnose and resolve permissions issues:

  1. Enable JPS logging. The default logging level is usually not sufficient to discover the source of AccessControlException errors. Using a finer detail on logs allows you to see the exact code base that is executing the unauthorized operation.
    1. Open the Oracle WebLogic Server Administration Console, and on the Domain Structure tree, expand Environment. Select Servers, then click the managed server name.
    2. Select the Server Start tab, click Lock & Edit, and then add the following Arguments to the end of the argument list:
      -Djps.auth.debug=true
Djps.auth.debug.verbose=true
    3. Click Save and then click Activate Changes. Then, restart the managed server.
    4. Replicate the use case that is causing the AccessControlException and then search the managed server .out log file for the entries being logged. Search for the string FAILED. For example:
      [OpsAuth] Check Permission
	  PolicyContext:        [oauth-client]
	  Resource/Target:      [context=SYSTEM,mapName=user.public.map,keyName=SaaSSystemAccount]
	  Action:	        [read]
	  Permission Class:     [oracle.security.jps.service.credstore.CredentialAccessPermission]
	  Result:	        [FAILED]
	  Evaluater:	     [ACC]
	  Failed ProtectionDomain:ClassLoader-weblogic.utils.classloaders.GenericClassLoader@5Da796tt...
      Make sure that the PolicyContext, Resource/Target, Action, and Permission Class match those being shown by the exception.
    5. Check the CodeSource block shown immediately below the log snippet in the previous step. The file listed is the jar executing the code with the missing permission. For example:
      CodeSource-file:/u01/data/domains/wls_domain/servers/wls_server_1/tmp/_WL_user/oauth-client/kk4bjg/lib/PublicReportServiceWSClient-1.0.11.jar
  2. Grant a permission for this code base. You can do this using the WLST command-line tool, or by using Oracle Enterprise Manager Fusion Middleware Control. The following steps show how to grant permission using Oracle Enterprise Manager.
    For details on using WLST, log in to My Oracle Support and search for the article Doc ID 1327577.1.
    1. Log in to Oracle Enterprise Manager Fusion Middleware Control and from the WebLogic Domain drop down menu, select Security and then System Policies. Click Create new Security Grant.
    2. In the Create System Grant page, under CodeBase, add the codeSource file found in the log file.
      Substitute environment variables to avoid using the actual file path. For example, the variable oracle.deployed.app.dir points to the _WL_user folder in the example file path given in the previous step's example log error jar file. You can also use the environment variable oracle.deployed.app.ext to apply the permission to everything under the current path.
      For example:
      file:${oracle.deployed.app.dir}/MassItem28B${oracle.deployed.app.ext}
    3. Click Add. Check the Select here to enter details for a new permission option, and fill in the details:
      • Permission Class: oracle.security.jps.service.credstore.CredentialAccessPermission
      • Resource Name: context=SYSTEM,mapName=user.public.map,keyName=SaaSSystemAccount
      • Permission Actions: read
    4. Click OK. Review the information and click OK to save changes.
After granting permission, usually no restart is necessary, but if the issue still occurs, restarting the server may resolve it. After resolving one access denied error, you may now see a new error on another codeSource, as more of your Java code is able to execute. Consequently you may need to repeat this process of reviewing the log, granting a new permission to another jar file, and then re-testing multiple times until you have resolved all of the permissions issues.