Considerations When Developing Applications on Oracle Java Cloud Service

Considerations When Developing Applications on Oracle Java Cloud Service - SaaS Extension

When developing applications to deploy to an Oracle Java Cloud Service - SaaS Extension instance, you need to consider the supported application standards and APIs available to ensure successful deployment.

Topics

About Underlying Oracle Technologies

Think of each Oracle Java Cloud Service - SaaS Extension instance as a deployment target for applications using a set of Java EE release 5, Java EE release 6, and Oracle WebLogic Server capabilities.

Oracle Java Cloud Service - SaaS Extension is built on the following Oracle technologies:

Oracle WebLogic Server (WebLogic Server) release 10.3.6
Oracle Application Development Framework (ADF) release 11.1.1.9.0 (11.1.1.7.1 for Service instances created before February 3, 2017)

Note:

All references in this document to WebLogic Server capabilities and ADF specific capabilities refer only to the releases specified in the previous list.

About Supported Applications, Standards, and APIs

Oracle Java Cloud Service - SaaS Extension supports the deployment of many types of applications and technology standards:

These applications and standards are:

WAR or EAR Deployment

Web Application Archive (WAR) or Enterprise Archive (EAR) deployment. All supported applications must be deployed through a WAR file or an EAR file (which can contain multiple WAR or JAR files).

Tip:

The class loader behavior of EAR archives when deployed to an Oracle Java Cloud Service - SaaS Extension is the same as that of WebLogic Server. See Understanding WebLogic Server Application Classloading in Oracle Fusion Middleware Developing Applications for Oracle WebLogic Server.

ADF Applications

Oracle Application Development Framework (ADF) 11.1.1.9.0 applications are supported.

Web Applications

Applications using Servlet 2.5, JavaServer Pages (JSP) 2.1, Java Server Faces (JSF) release 1.2 and release 2.0.
Use of web.xml and weblogic.xml deployment descriptors, and related annotations are supported.

Web Services Applications

Applications using Java API for XML Web Services (JAX-WS) 2.1 based web services. Use of webservices.xml, weblogic-webservices.xml deployment descriptors and related annotations is supported.
Applications providing REST-based APIs through Java API for RESTful web services (JAX-RS) 1.1 and Jersey 1.9 annotations are supported.

Enterprise Java Beans (EJB) Containers

Applications using EJB 2.1 and EJB 3.0 specifications. Use of ejb-jar.xml, weblogic-ejb-jar.xml, and related annotations are supported with the following exceptions:

Only local EJB invocations are supported, specifically, the client code invoking an EJB application's interface must be either within the same deployment archive as the EJB implementation code itself or within a deployment archive that is deployed to the same Oracle Java Cloud Service - SaaS Extension instance.
EJB 2.x Entity Beans are not supported.

JDBC Services

Applications using Java Persistence API (JPA) 2.0 specifications and use of JPA persistence.xml elements with EclipseLink 2.1.3 specific extensions.
Direct use of Java Database Connectivity (JDBC) 4.0 APIs. See WebLogic Server 12.1.1 Compatibility with Previous Releases in Oracle Fusion Middleware Upgrade Guide for Oracle WebLogic Server.
Use of Oracle Database 11g compatible SQL statements.
JDBC Data Sources provisioned within an Oracle Java Cloud Service - SaaS Extension instance upon association with a Database Cloud Service instance will be XA-enabled JDBC data sources.

Java Platform, Standard Edition (SE) 1.6 or 1.7 APIs

Applications can use the set of Java SE 1.6 or 1.7 public APIs, as long as they pass the Oracle Java Cloud Service - SaaS Extension whitelist tool, and that their use is in-line with Java EE best practices. See Oracle Java Cloud Service - SaaS Extension Whitelist Validation.

Other Supported Java EE 5 and 6 Specifications

This section describes other Java EE 5 and Java EE 6 specifications supported by the Oracle Java Cloud Service - SaaS Extension.

Tip:

Some Java EE specifications in this section relate purely to the underlying Java EE container environment and are irrelevant to the actual Java EE deployment archives and how they are developed (for example, Java Authentication and Authorization Service (JaaS)). Although these specifications are supported, they are not listed here.

Supported Specification	Supported Version
JavaServer Pages Standard Tag Library (JSTL)	1.2
Java Data Base Connectivity (JDBC)	4.0
Java Persistence API	2.0
Web Services Metadata for the Java Platform	2.0
Java Naming and Directory Interface Specification (JNDI)	1.2
Java Transaction API (JTA)	1.1
Streaming API for XML (StAX)	1.0
SOAP with Attachments API for Java (SAAJ)	1.3
JavaBeans Activation Framework Specification (JAF)	1.1
Java API for XML Processing (JAXP)	1.3
Java Management Extensions (JMX) Note: JMX is only supported for exposure of MBeans within a deployment archive and access to these MBeans from the deployment archive itself or other archives deployed to the same Oracle Java Cloud Service - SaaS Extension instance.	1.2
Java API for XML-based Web Services (JAX-WS)	2.1
Java API for RESTful Web Services (JAX-RS)	1.1
Java Architecture for XML Binding (JAXB)	2.0

Other Supported Public WebLogic Server 10.3.6 APIs and Capabilities

This section describes additional public WebLogic Server 10.3.6 APIs and capabilities supported by the Oracle Java Cloud Service - SaaS Extension.

Note:

As a best practice, Oracle recommends that you always use standard Java APIs for your Oracle Java Cloud Service - SaaS Extension and avoid using WebLogic Server APIs to ensure that your applications are portable to other environments. This way your applications will not get locked into running only on the Oracle Oracle Java Cloud Service - SaaS Extension.

API	Description
`weblogic.logging.*`	Used for internal (non-catalogue) WebLogic server logging
`weblogic.jsp.*`	For applications using custom WebLogic Server specific tags
`weblogic.cache.*`	Response caching servlet filter
`weblogic.application.*`	Used for implementation of application life-cycle listeners
`weblogic.i18n.*`	Public I18N APIs and logging
`weblogic.i18ntools.*`	Public I18N APIs and logging
`weblogic.jndi.*`	For Java Naming and Directory Interface (JNDI) lookup within WLS JNDI tree
`weblogic.jws.*`	WebLogic specific extensions to JAX-WS for supporting WS-*
`weblogic.servlet.*`	For annotations based servlet descriptions
`weblogic.transaction.*`	API used for direct JTA interaction

Using Third-Party Frameworks with Oracle Java Cloud Service - SaaS Extension

You can use third-party frameworks to extend the functionality of Oracle Java Cloud Service - SaaS Extension.

You can use each of these frameworks with Oracle Java Cloud Service - SaaS Extension in one of the following ways:

Packaging the framework with applications that use it
Deploying the framework as a shared library
For more information, see Deploying, Redeploying, and Deleting Libraries.

If multiple applications use a framework, or if you want to simplify updates by minimizing the size of applications that use the framework, deploy the framework as a shared library.

Topics

Supported Third-Party Frameworks for Oracle Java Cloud Service - SaaS Extension

Oracle Java Cloud Service - SaaS Extension supports several third-party frameworks.

Framework	Release	Purpose
Apache Commons component BeanUtils	1.9.2	Simplify the use of the Java reflection and introspection APIs.
Apache Commons component Collections	3.2.1	Extend or augment the Java Collections Framework.
Apache Commons component Digester	3.2	Map XML configuration data to Java objects.
Apache Commons component IO	2.4	Help develop functionality for input and output through data streams.
Apache Commons component Logging	1.2	Enable a library to be used with a chosen logging implementation at runtime.
Apache log4j	1.2.17 2.0	Enables logging at runtime without modifying the application binary and allows these statements to remain in shipped code without incurring a heavy performance cost.
Apache Struts	2.3.3	Simplify the development of Java web applications that use a Model-View-Controller (MVC) architecture.
Apache Tapestry	5.3.6	Used for creating dynamic, robust, highly scalable web applications in Java.
Apache Wicket	6.18.0	Simplify the development of Java web applications by: Properly separating markup and logic Using a Plain Old Java Object (POJO) data model Limiting the use of Extensible Markup Language (XML) configuration files
FreeMarker	2.3.19	A Java package or class library used by Java programmers to generate template-based text output (anything from HTML to auto-generated source code).
Google Guice	3.0	An open source software Java framework that provides support for dependency injection by using annotations to configure Java objects.
Google Web Toolkit (GWT Web Toolkit)	2.5.1	Provides a framework for creating and maintaining complex JavaScript front-end applications in Java.
Hibernate ORM	4.2.4	Provide a framework for mapping an object-oriented domain model to a traditional relational database.
JodaTime	2.1	Serves as the de facto standard date and time library for Java applications.
JQuery	2.0.3	Provide a JavaScript library to simplify HTML document traversal and manipulation, event handling, animation, and Ajax.
Play	2.1.0	Optimizes your productivity by using convention over configuration, hot code reloading and browser display of errorsr.
Quartz Job Scheduler	2.1.5	Create simple or complex schedules for executing jobs whose tasks are defined as standard Java components.
SLF4J (Simple Logging Facade for Java)	1.7.7	Provides a simple facade or abstraction for various logging frameworks (`java.util.logging`, logback, log4j) which allows end users to plug in the desired logging framework at deployment time.
Spring	3.0	Provides a comprehensive programming and configuration model for modern Java-based enterprise applications, regardless of their deployment platform.

Omitting Checks for Updates to Quartz Job Scheduler

By default, Quartz Job Scheduler checks for updates when it starts.

The check for updates involves connecting to a remote server. If the server cannot be reached, the check fails and an exception is written to log file. The failure does not prevent Quartz Job Scheduler from starting and does not affect the functionality of Quartz Job Scheduler in any way. However, you can prevent this exception by omitting checks for updates to Quartz Job Scheduler.

To omit checks for updates to Quartz Job Scheduler, use the Oracle Java Cloud Service - SaaS Extension SDK to set the Quartz configuration property org.quartz.scheduler.skipUpdateCheck to true.

See the following Quartz Job Scheduler documentation:

Skip Update Check in Best Practices
Configure Main Scheduler Settings in Configuration Reference

Using Non-Listed Frameworks

You can use third-party frameworks not included on the approved list but you need to be careful that these frameworks are valid.

While Oracle strongly recommends that you limit your use of third-party frameworks to only those that have been tested and approved (see Supported Third-Party Frameworks for Oracle Java Cloud Service - SaaS Extension), that doesn’t mean that non-listed libraries won’t work. If you chose to use a non-listed framework, you should use the Whitelist Tool to validate the framework. The Whitelist tool performs a type of compatibility test on every application installed or updated in a Java Cloud Service - SaaS Extension instance by validating deployment descriptors and other application configuration files. If you use the tool during runtime, you will need to address any warning that are generated.

Run the Whitelist Tool by issuing this command:

./whitelist [-argument ...] [-help] [file1 file2 dir1 dir2 ...]

For example:

./whitelist -log /home/log/newlog.log /home/apps/myapp.war

The valid arguments for -whitelist are described in Use the Whitelist Tool.

About the Application Deployment Validation Process and Run-time Security

During the Oracle Java Cloud Service - SaaS Extension deployment process, every application or library undergoes a series of security checks before that application or library is actually deployed. For technical and security reasons, a small number of specific APIs are prevented from executing in Oracle Cloud.

Note:

During application deployment and at run-time, the Oracle Java Cloud Service - SaaS Extension utilizes both the Java Security Manager and a whitelisting tool to enforce certain API restrictions. However, these API validations are not the primary security defense mechanisms for Oracle Java Cloud Service - SaaS Extension. Oracle Cloud has extensive primary security defense mechanisms at the VM, OS and network layers.

The Java Security Manager performs additional security validation during application run-time. For example, an application that has packaged some third-party JAR files that have API violations are permitted to be deployed as long as the violated usages are not exercised during run-time. Security exceptions will be raised when those APIs are exercised.

For additional information, see Unsupported Features and APIs.

Application and Library Deployment Validation Flow

Every application or library that is being deployed undergoes background security checks before that application is attempted to deployed.

The background and security checks follow this sequence:

Virus scan
Whitelist validation
WLS compile
Cloud compile
Deploy

For a typical deployment, Oracle Java Cloud Service - SaaS Extension generates five logs, one for each of these security checks. These logs are the result of background jobs that ran against the application and determined whether the application contains a virus or could otherwise cause problems. See Viewing the Activity Logs.

Oracle Java Cloud Service - SaaS Extension Whitelist Validation

The Whitelist tool validates deployment descriptors and other application configuration files, such as the log4j.properties file, as part of the Java API validation.

If an application contains any Java API validations, the Whitelist tool might not reject it from being deployed. Instead, it would create a warning report against the violations. A security exception will be raised only during runtime, should those exceptions be exercised when the application is running. For example, it is common for third-party libraries to raise warnings during Whitelist validation; however, they are rarely exercised during runtime.

For instructions on downloading the SDK, see Downloading the Oracle Java Cloud Service - SaaS Extension SDK.

Note:

The Oracle Java Cloud Service - SaaS Extension "whitelist" is actually the result of what are sometimes called blacklist and whitelist checks. It may be helpful to think of Oracle Java Cloud Service - SaaS Extension whitelist validation as simply a compatibility check.

After automatic whitelist validation, if you are encountering additional deployment problems, you can locally validate an application by using the Whitelist Tool (whitelist.jar), which is available in the Java Cloud Service - SaaS Extension SDK. See Use the Whitelist Tool.