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.
Oracle Java Cloud Service - SaaS Extension provides out-of-the-box support for Single-Sign On (SSO) between applications deployed on it and Oracle Software as a Service offerings (like Sales Cloud, Service Cloud, Marketing Cloud, and so on). Enabling SSO capabilities requires no effort on your part. SSO is not included in Oracle Java Cloud Service but can be configured in WebLogic by using the administration console.
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.
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.
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.
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.
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.
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.