How is Oracle Java Cloud Service - SaaS Extension different from Oracle Java Cloud Service?
Like Oracle Java Cloud Service, Oracle Java Cloud Service - SaaS Extension provides an enterprise-grade platform to develop and deploy business applications in the cloud. The differences lie in how you will use the service: Java Cloud Service supports deployment of custom business application development while you would use Java Cloud Service–SaaS Extension to build extensions to existing Oracle SaaS products, such as CRM, HCM, and so on.
Some of the major difference between these two services are:
Oracle Java Cloud Service - SaaS Extension supports standard Java Platform, Enterprise Edition (Java EE) 5, whereas, Oracle Java Cloud Service supports standard Java Platform, Enterprise Edition (Java EE) 6. Both services support Oracle Application Development Framework applications.
While both services can be managed and monitored through their specific consoles—Java Cloud Service - SaaS Extension Control and the Java Cloud Service Console (both web-based interfaces)—Oracle Java Cloud Service - SaaS Extension can also be controlled via a command-line interface available with the Java Cloud Service - SaaS Extension SDK. Conversely, Oracle Java Cloud Service can be managed through REST APIs.
With Oracle Java Cloud Service - SaaS Extension, you cannot access the configuration of the underlying application server, JVM, and/or operating system for any services, while this is possible with Oracle Java Cloud Service.
Java Cloud Service - SaaS Extension supports Single-Sign On (SSO) out of the box. Once federation is enabled in the data center where your Software as a Service (such as Sales Cloud, Service Cloud, Marketing Cloud, and so on) is running, your Java Cloud Service - SaaS Extension applications won’t require any changes to enable SSO capabilities.
With Oracle Java Cloud Service - SaaS Extension, you deploy applications directly from Oracle Java Cloud Service - SaaS Extension Control (a web-based console), whereas you deploy applications for Oracle Java Cloud Service by using Fusion Middleware Control, the WebLogic Server Administration Console, WebLogic Scripting Tool (WLST) commands, or an IDE.
Currently, Oracle Java Cloud Service - SaaS Extension is available to customers in North America and Europe. Oracle Java Cloud Service is available only from North American data centers.
For more detailed information and comparisons between both services, see the Oracle Cloud Java FAQ.
How do I create an on-premise WebLogic Server environment that is comparable to an Oracle Java Cloud Service - SaaS Extension instance?
An on-premise environment is a local WebLogic Server/Java EE environment that is comparable to an Oracle Java Cloud Service - SaaS Extension instance. An on-premise environment is useful for both developing and troubleshooting applications deployed to Oracle Java Cloud Service - SaaS Extension. For more information, see Creating an On-premise WebLogic Server Environment.
Can I set Log4j or JDK logging levels for my applications?
Yes, by using commands available from the Java Cloud Service - SaaS Extension SDK. This feature is particularly useful when you want to adjust the log level of loggers your application is using as it allows you to control the debugging resolution of the log statements. For more information and a list of logging commands, see Managing Logging Levels. For information on acquiring the Java Cloud Service - SaaS Extension SDK, see Downloading the Oracle Java Cloud Service - SaaS Extension SDK.
If I'm using the JDeveloper IDE can I use Log4j with applications deployed to Oracle Java Cloud Service - SaaS Extension?
Yes, however, Log4j is not part of the libraries available in JDeveloper, so you would need to explicitly download and include the Log4j library into your application.
Do I need to put my Log4j properties files in a particular location?
Oracle Cloud does not affect Log4j's mechanism for locating its own configuration files; therefore, the location of Log4j properties files should be by default found on the system
CLASSPATH. Note that FileAppenders can only write to
/customer/scratch/**. For configuration file information see the Log4j documentation. For more information applications accessing system properties, see Guidelines for Applications When Accessing System Properties.
How do I pass UTF-8 encoded characters in the request URL and how do I get the value into the application?
Pass the encoded character in a format like
To get the actual value back from a servlet you must to do the following:
String paramValue = request.getParameter("myparam"); \\returns value encoded in WLS default encoding that is iso-8859-1 paramValue = new String(paramValue.getBytes("iso-8859-1"),"UTF-8") ; \\Encodes to UTF-8 now.
An application, for example "gbk”, can override the default WLS encoding. If that happens, set a
paramValue variable as follows:
paramValue = new String(paramValue.getBytes("gbk"),"UTF-8") ;
Can I change a service name after I’ve already activated the service?
No. The service name is unique within an identity domain and is used as part of the service URL, as shown in Activating Paid Database and Java Services Together. it cannot be changed.