Difference between Jserv and OC4J

Oracle 11i uses Jserv as the servlet engine. R12 uses OC4J as the servlet engine.

In Oracle9iAS Release 1 (1.0.2.2.x), the first release to include OC4J, there were two JSP containers:

The container developed by Oracle and formerly known as "OracleJSP"

The container licensed from Ironflare AB and formerly known as the "Orion JSP container". Apps 11i uses Orion JSP container.

The OracleJSP container offered a number of advantages, including useful value-added features and enhancements such as for globalization and SQLJ support. The Orion container also offered advantages, including superior speed, but had disadvantages as well. It did not always exhibit standard behavior when compared to the JSP 1.1 reference implementation (Tomcat), and its support for internationalization and globalization was not as complete.

In Oracle9iAS Release 2 (9.0.2) and higher, these two containers are integrated into a single JSP container, referred to as the "OC4J JSP container". This container offers the best features of both original versions and runs efficiently as a servlet in the OC4J servlet container. The integrated container primarily consists of the OracleJSP translator and the Orion JSP runtime, running with a simplified dispatcher and the OC4J core runtime classes.

In Oracle9iAS Release 1 (1.0.2.2.x), JServ was the primary servlet environment. There are significant differences between the OC4J 9.0.4 servlet environment, which is a servlet 2.3 implementation, and the JServ servlet environment, which is a servlet 2.0 implementation. The following is a summary of highlights, particularly with respect to JSP implementations:

Standard application environment versus globals.jsa: A well-defined concept of a Web application exists in the servlet 2.3 definition, but did not exist in the servlet 2.0 definition. The servlet standard and OC4J implementation now define the concept of the document root of a Web application, and how to package an application.

Request dispatcher: The concept of the request dispatcher was introduced in the servlet 2.1 specification. This mechanism allows a JSP page or servlet to include content from another page or servlet or to forward execution to another page or servlet. For JServ, the OracleJSP implementation (but not the Orion JSP implementation) in Oracle9iAS Release 1 (1.0.2.2.x) emulated request dispatcher functionality. For OC4J in Oracle Application Server 10g (9.0.4), this emulation is no longer necessary.

Attribute storage: Beginning with the servlet 2.1 specification, request-level and application-level attribute storage is possible. Developers can use HTTP request objects and servlet context (application-level) objects to store and retrieve state information. For JServ, the OracleJSP implementation (but not the Orion JSP implementation) in Oracle9iAS Release 1 (1.0.2.2.x) emulated this functionality. For OC4J in Oracle Application Server 10g (9.0.4), this emulation is not necessary.

Servlet filtering: The concept of servlet filtering was introduced in the servlet 2.3 specification. This mechanism allows verification and modification of HTTP request and response objects by developers. This might be used, for example, for common headers and footers or customized authentication or authorization. This functionality was not available in Oracle9iAS Release 1 (1.0.2.2.x) but is available in Oracle Application Server 10g (9.0.4).

Globalization: The servlet 2.3 specification provides globalization support for HTTP parameters through the standard setCharacterEncoding() method of the HTTP request object. The OracleJSP implementation (but not the Orion JSP implementation) in Oracle9iAS Release 1 (1.0.2.2.x) supported globalization through the translate_params configuration parameter. Later OC4J JSP implementations also supported globalization through the setReqCharacterEncoding() method of a public utility class. You should now migrate your applications to setCharacterEncoding().