No. If there is an Oracle-specific implementation of JSF, ADF Faces will be optimized to run best on that implementation, but we believe it is important that ADF Faces run on any implementation of the JSF 1.1 specification (or later). ADF Faces can be used with either the Sun Reference Implementation 1.1_01 or MyFaces 1.0.8 (or later).

Please see the platform section on the installation page for information on how to deploy to JDeveloper, standalone OC4J, and Tomcat.

Although ADF Faces is "vanilla" JSF we have not been able to run with Java Studio Creator Build 04.06.2. We are working with Sun to resolve the issues in Java Studio Creator.

We have done some limited testing on IBM WebSphere Studio Application Developer 5.1.2. We have been able to run using .jsp, but not .jspx. If you are running the demo WAR please make sure the file names in faces-config.xml reflect any updated file names.

Yes; all standard Faces tags can be used with ADF Faces. You can even use < h:form > instead of < af:form > without losing any ADF Faces functionality.

Good question. Here's a list of some of the advantages

Note: The items in italics are either not yet available or only partially implemented

1. Provide more efficient implementations of client-side state saving (reduced per-component size)
2. Rich set of components, validators, and converters
3. ADF Faces tags often offer more features than the standard tags; for example, all input components offer built-in label and message display support ( For more information on the differences between the ADF Faces tags and the standard Faces tags, please see the following document ).
4. Client-side converters/validators - JavaScript enabled converters and validators that attempt to catch and display errors on the client
5. ADF Faces tags can be used inside of the < af:forEach > tag (it is, unfortunately, not possible to support standard tags inside < af:forEach > ).
6. Accessibility - support similar to ADF UIX Accessibility
7. Bidirectional language support - ADF Faces components automatically render themselves appropriately for bidirectional languages. Users can also use the "start" and "end" constants described in ADF UIX Bidirectional Language Support
8. Partial Page Rendering (PPR) - support similar to ADF UIX PPR overview
9. Skinning - support similar to ADF UIX Look and Feel
10. ADF integration - including support for JSR227 (Data binding)
11. Rich Client - upcoming rich DHTML client-side renderers

ADF Faces is a significant evolution of the previous ADF UIX code. The proprietary API ( UINode , RenderingContext , etc.) of ADF UIX has been replaced with the standard JSF API, and we've added many features to our components that take advantage of the JSF architecture. In making this change, we've also overhauled nearly all our component names and attribute names to fit in closely with JSF naming conventions. ADF UIX and ADF Faces can be installed in a single web application without conflicts.

You cannot directly point to a JSF JSP file; you either need to add "/faces" after the servlet context path, or change the suffix (in the URL only) to ".faces".

JSF requires the < f:view > JSP tag around all JSF JSP tags; this obscure error is the result of failing to include < f:view > .

You may have trouble seeing dialogs if you have popup blockers installed.

You are using JSF 1.0 (this is a bug in the JSF 1.0 RI) and ADF Faces requires JSF 1.1.

You need to enable J2SE 1.4 Assertions. In jdev this can be done in project properties (Select Tools -> Project Properties -> Profiles -> Development -> Compiler -> Enable J2SE 1.4 Assertions.)

You may have not have configured your Resources Servlet in your web.xml. Please refer to installation instructions to configure the ResourceServlet.

You may be missing the "setXyz()" function matching the "getXyz()" function that is controlling your field's value, or you might have mispelled its name. This makes that property read-only. When ADF Faces detects that an input field is using a read-only model property, it automatically switches the field to read-only mode, which is why it looks like plain text. For what it's worth, if you tried the same model property with < h:inputText > , it'd look fine when you first render the page, but JSF would throw an exception when you posted back to the server and it couldn't write the new value into the model.