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.


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


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).


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 as described in Understanding WebLogic Server Application Classloading in Oracle Fusion Middleware Developing Applications for Oracle WebLogic Server.

ADF Applications

Oracle Application Development Framework (ADF) 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 as described in 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.


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)


Java Data Base Connectivity (JDBC)


Java Persistence API


Web Services Metadata for the Java Platform


Java Naming and Directory Interface Specification (JNDI)


Java Transaction API (JTA)


Streaming API for XML (StAX)


SOAP with Attachments API for Java (SAAJ)


JavaBeans Activation Framework Specification (JAF)


Java API for XML Processing (JAXP)


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.


Java API for XML-based Web Services (JAX-WS)


Java API for RESTful Web Services (JAX-RS)


Java Architecture for XML Binding (JAXB)


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.


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


Used for internal (non-catalogue) WebLogic server logging


For applications using custom WebLogic Server specific tags


Response caching servlet filter


Used for implementation of application life-cycle listeners


Public I18N APIs and logging


Public I18N APIs and logging


For Java Naming and Directory Interface (JNDI) lookup within WLS JNDI tree


WebLogic specific extensions to JAX-WS for supporting WS-*


For annotations based servlet descriptions


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:

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.

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



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.

(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.

For more information, see the following Quartz Job Scheduler documentation:

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.


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:

  1. Virus scan

  2. Whitelist validation

  3. WLS compile

  4. Cloud compile

  5. 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. For more information, 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 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.


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 For more information on this process, see Use the Whitelist Tool.