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
andweblogic.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 |
---|---|
|
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:
- 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.
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:
|
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.
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.