Brenden Anstey
![Subscribe to Brenden Anstey feed](http://www.orafaq.com/misc/feed.png)
JDeveloper, Java Server Faces, ADF Business ComponentsBrenden Ansteyhttp://www.blogger.com/profile/09715936768254537319noreply@blogger.comBlogger11125
Updated: 11 hours 56 min ago
How to run eBusiness Suite R12 using IE8
IE8 is not supported for R12 as yet but it does work by disabling a security setting related to Cross Site Scripting (XSS). This solution works on Vista 64 using IE8 on Release 12.1
Here is how to do it:
Firstly we need to add the EBS application server to trusted sites within IE as we definitely do want the IE8 XSS filter active for general Internet browsing.
1. In IE8 Select Tools->Internet Options->Security(tab)->Trusted Sites
2. Click Sites and type in the hostname of the server running R12, untick Require HTTPS if needed and add the website to the list of trusted sites. Hit close.
3. Still in the Security tab click the custom level button and scroll right to the bottom and the third option from the bottom at the time of writing is 'Enable XSS Filter" set the option value to Disable.
Make sure you only disable the XSS filter for Trusted sites which should be a small list of intranet servers that you trust the content from.
Browse JAR, WAR and EAR files in Explorer
Found this really neat method if getting the Windows Zip Explorer Compressed (zipped) Folders extension to read JAR, WAR and EAR files in Windows Explorer.
Instructions
Open notepad and paste the below Registry Entries into a text file named ear-jar-war.reg, save it on your desktop and then run it. This will associate the three types with the the Zip shell extension: Compressed (zipped) Folders
If any of the extensions are associated with something else, Compressed (zipped) Folders will now appear in the recommended programs for these file types so you can associate them manually.
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.jar]
"Content Type"="application/x-zip-compressed"
"PerceivedType"="compressed"
@="CompressedFolder"
[HKEY_CLASSES_ROOT\.jar\CompressedFolder]
[HKEY_CLASSES_ROOT\.jar\CompressedFolder\ShellNew]
"Data"=hex:50,4b,05,06,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
[HKEY_CLASSES_ROOT\.jar\OpenWithProgids]
"CompressedFolder"=""
[HKEY_CLASSES_ROOT\.jar\PersistentHandler]
@="{098f2470-bae0-11cd-b579-08002b30bfeb}"
[HKEY_CLASSES_ROOT\.war]
"Content Type"="application/x-zip-compressed"
"PerceivedType"="compressed"
@="CompressedFolder"
[HKEY_CLASSES_ROOT\.war\CompressedFolder]
[HKEY_CLASSES_ROOT\.war\CompressedFolder\ShellNew]
"Data"=hex:50,4b,05,06,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
[HKEY_CLASSES_ROOT\.war\OpenWithProgids]
"CompressedFolder"=""
[HKEY_CLASSES_ROOT\.war\PersistentHandler]
@="{098f2470-bae0-11cd-b579-08002b30bfeb}"
[HKEY_CLASSES_ROOT\.ear]
"Content Type"="application/x-zip-compressed"
"PerceivedType"="compressed"
@="CompressedFolder"
[HKEY_CLASSES_ROOT\.ear\CompressedFolder]
[HKEY_CLASSES_ROOT\.ear\CompressedFolder\ShellNew]
"Data"=hex:50,4b,05,06,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
[HKEY_CLASSES_ROOT\.ear\OpenWithProgids]
"CompressedFolder"=""
[HKEY_CLASSES_ROOT\.ear\PersistentHandler]
@="{098f2470-bae0-11cd-b579-08002b30bfeb}"
Oh and of course back up your registry before running. As you can see from above it only adds some keys to HKEY_CLASSES_ROOT, tested in XP, but at your own risk and all that ;)
How to find, share and back up JDeveloper code templates
JDeveloper code templates are stored in the JDevHome folder in an XML file called java.tpl. This is one file worth backing up if you have a lot of custom code templates.
The file is in [Drive:]\JDevHome[Version]\system\oracle.jdeveloper.[version] eg.
C:\JDev\IDE\JDevHome10.1.3.3_1\system\oracle.jdeveloper.10.1.3.41.57
Free software I wouldn't be without
Here are some tool-utilities-programs I wouldn't be without. All free and very useful:
PuTTY : SSH Client : Link
UnxUtils: grep, cut and ls your way around Windows : Link
CutePDF : Convert ANY document to PDF : Link
Foxit: Lightweight fast PDF reader: Link
XML Notepad : Free XML tool from Microsoft : Link
Collabnet Subversion : Powerful source control : Link
TortoiseSVN : Explorer extension and GUI for Subversion: Link
J2EE Container Managed Security: How to reference the current user
When J2EE container managed security is used the User Principal can be referenced in a number of ways:
Expression Language
<af:outputText value="#{facesContext.externalContext.userPrincipal.name}"/>
Managed / Backing Bean
ExternalContext ectx = FacesContext.getCurrentInstance().getExternalContext();
String userName = ectx.getUserPrincipal().getName();
System.out.println("Current user: " + userName);
ADF BC Application Module
String userName = getUserPrincipalName();
System.out.println("Current user: " + userName);
Programmatically removing all entities from a view object
Recently I had a case where I needed to remove all rows from a view object and found that there was no existing method to do this.
The case for doing such an action is where there is a Master-Detail relationship and the detail relation is used only of there is a certain condition met in the master. If the condition is met then the detail is required, however if the user changes their mind then we need a way of removing any records that may have been created in the detail.
By adding the following method in the View Object Implementation class we can safely delete all records in the view object:
The case for doing such an action is where there is a Master-Detail relationship and the detail relation is used only of there is a certain condition met in the master. If the condition is met then the detail is required, however if the user changes their mind then we need a way of removing any records that may have been created in the detail.
By adding the following method in the View Object Implementation class we can safely delete all records in the view object:
public void removeAllRows(){
// rangeSize is -1
Row[] rows = getAllRowsInRange();
for (int r = 0; r < rows.length; r++)
if (rows[r] != null)
rows[r].remove();
}
How to reduce coding by extending Managed Beans
After coding many backing/managed beans it became clear to me that there were a few things that I seem to be doing over and over, these were:
An example usage in a backing bean Employees.java, extends JSFBean:
- Getting values from the binding layer
- Setting values in the binding layer
- Executing operation bindings
- Using a combination of the above in a backing bean method
The logical thing to do was be to but my code for doing this into a class and extend this class for all of my managed beans. The class is called JSFBean and uses the binding "#{bindings}" to access the binding container. The three methods in the class (so far) are: execute, getValue and setValue.
The bean which I have called JSFBean includes these three methods and some basic error handling. When creating a backing bean simply add "extends JSFBean" to the class definition.
JSFBean.java:package com.delexian.ui.backing;
import javax.faces.application.FacesMessage;
import javax.faces.context.FacesContext;
import javax.faces.el.ValueBinding;
import oracle.adf.model.binding.DCBindingContainer;
import oracle.binding.OperationBinding;
public class JSFBean {
public JSFBean() {
}
public DCBindingContainer getBindings() {
FacesContext fc = FacesContext.getCurrentInstance();
ValueBinding vb = fc.getApplication().createValueBinding("#{bindings}");
DCBindingContainer dc = (DCBindingContainer) vb.getValue(fc);
return dc;
}
public boolean execute(String operation){
DCBindingContainer bindings = getBindings();
OperationBinding operationBinding = bindings.getOperationBinding(operation);
if (operationBinding == null){
FacesContext fc = FacesContext.getCurrentInstance();
fc.addMessage("Invalid Operation", new FacesMessage(operation + " is not a valid operation for this page"));
return true;
}
operationBinding.execute();
return operationBinding.getErrors().isEmpty();
}
public Object getValue(String el){
FacesContext fc = FacesContext.getCurrentInstance();
ValueBinding expr = fc.getApplication().createValueBinding(el);
return expr.getValue(fc);
}
public void setValue(String el, Object value){
FacesContext fc = FacesContext.getCurrentInstance();
ValueBinding expr = fc.getApplication().createValueBinding(el);
expr.setValue(fc, value);
}
}
An example usage in a backing bean Employees.java, extends JSFBean:
package com.delexian.ui.backing;
public class Employees extends JSFBean {
public Employees() {
}
public String calculate_action() {
execute("CalculateCommission");
execute("Commit");
return null;
}
}
An ADF Faces and XML Publisher Success Story
Deciding on an output mechanism for the application
After months of developing an application using ADF Faces and ADF Business components it came time to solve the last of my integration and design issues: Integrating a reporting/output mechanism. Early in the project I considered the option of using Oracle Reports or doing (redoing) printable versions of the entire entry form. With over 40 sections to the online application form, neither of these options seemed desirable or suitable.
At a recent conference XML Publisher generated quite a lot of interest so I thought I would download it and see what the hype was about. It didn't take long to work out that XML Publisher was going to be the tool of choice for my application. The original Word documents that the application was built from could be used with the data plugged straight in to where it needed to go. One of the big gains was not having to worry about formatting, this alone saved a huge amount of time.
Integrating XML Publisher with JDeveloper
Deepak Vohra has produced an article on OTN called Integrating Oracle XML Publisher with Oracle JDeveloper 10g which provided examples of using the XML Publisher API's in a simple Java Class. To start of with I created a small Java project based on one class which I executed from its Main method. This allowed me to get all the class paths and libraries sorted out and have me a good understanding of the XML Publisher Java API's. I was able to produce and merge PDF documents including page numbering in a very short space of time. I had to set enough memory for the XMP Publisher API's to overcome an out of memory error (Add "-Xmx256m"to your project run properties). The next step was to integrate this into a sandbox J2EE project and start writing to the browser response stream rather than disk. This presented a few challenges immediately, mostly around the location of the Data Template and XSL files which defined the output to be produced. In fact any interaction with the file system would prove to be a problem due to the relative execution changing to the location of the OC4J and not the class that is running. The other key problems were getting a pooled connection to the database and coding any file system operations to run in the embedded OC4J (XP) and target 10.1.3 middle tier (Linux).
Key design problems and their solutions
Getting a pooled connection for use by XML Publisher was solved by exposing a client method from the Application Module which returned a database connection from the connection pool. Getting the connection is described here in Steve Muench's blog.
The next design problem was where to actually call the XML Publisher API's to do all of the processing. The answer in short was a Managed Bean. The bean references the binding layer to get its parameters and is called by a JSP, which sets the response stream for the XML Publisher PDFDocMerger to write its PDF output to.
As for the interaction with the file system, I used a system properties table within the database which contained the various directories for the XML Data Templates and XSL style sheets for the output. I coded an AM method which used System.getProperties().getProperty("os.name"); to work out what OS the OC4J was running under and get the property for that Operating System eg. xmlp.windows.template.dir would get the full path on Windows for the XML Publisher template directory. (not quite write once - run anywhere, but close enough)
Summary
XML Publisher has been a huge win for this particular project and has successfully plugged a huge gap in the output mechanism for the application. The API's are comprehensive and every time looked to see if it could do something, the answer seemed to be yes and more! XML Publisher will definately be my preferred reporting tool for future ADF based projects.
After months of developing an application using ADF Faces and ADF Business components it came time to solve the last of my integration and design issues: Integrating a reporting/output mechanism. Early in the project I considered the option of using Oracle Reports or doing (redoing) printable versions of the entire entry form. With over 40 sections to the online application form, neither of these options seemed desirable or suitable.
At a recent conference XML Publisher generated quite a lot of interest so I thought I would download it and see what the hype was about. It didn't take long to work out that XML Publisher was going to be the tool of choice for my application. The original Word documents that the application was built from could be used with the data plugged straight in to where it needed to go. One of the big gains was not having to worry about formatting, this alone saved a huge amount of time.
Integrating XML Publisher with JDeveloper
Deepak Vohra has produced an article on OTN called Integrating Oracle XML Publisher with Oracle JDeveloper 10g which provided examples of using the XML Publisher API's in a simple Java Class. To start of with I created a small Java project based on one class which I executed from its Main method. This allowed me to get all the class paths and libraries sorted out and have me a good understanding of the XML Publisher Java API's. I was able to produce and merge PDF documents including page numbering in a very short space of time. I had to set enough memory for the XMP Publisher API's to overcome an out of memory error (Add "-Xmx256m"to your project run properties). The next step was to integrate this into a sandbox J2EE project and start writing to the browser response stream rather than disk. This presented a few challenges immediately, mostly around the location of the Data Template and XSL files which defined the output to be produced. In fact any interaction with the file system would prove to be a problem due to the relative execution changing to the location of the OC4J and not the class that is running. The other key problems were getting a pooled connection to the database and coding any file system operations to run in the embedded OC4J (XP) and target 10.1.3 middle tier (Linux).
Key design problems and their solutions
Getting a pooled connection for use by XML Publisher was solved by exposing a client method from the Application Module which returned a database connection from the connection pool. Getting the connection is described here in Steve Muench's blog.
The next design problem was where to actually call the XML Publisher API's to do all of the processing. The answer in short was a Managed Bean. The bean references the binding layer to get its parameters and is called by a JSP, which sets the response stream for the XML Publisher PDFDocMerger to write its PDF output to.
As for the interaction with the file system, I used a system properties table within the database which contained the various directories for the XML Data Templates and XSL style sheets for the output. I coded an AM method which used System.getProperties().getProperty("os.name"); to work out what OS the OC4J was running under and get the property for that Operating System eg. xmlp.windows.template.dir would get the full path on Windows for the XML Publisher template directory. (not quite write once - run anywhere, but close enough)
Summary
XML Publisher has been a huge win for this particular project and has successfully plugged a huge gap in the output mechanism for the application. The API's are comprehensive and every time looked to see if it could do something, the answer seemed to be yes and more! XML Publisher will definately be my preferred reporting tool for future ADF based projects.
Tips for using CVS with JDeveloper
Versions
Server: Linux OS, CVS Version 1.11.1p1
Client: Windows XP, JDeveloper 10.1.3.1 using ADF BC / Faces
Other tools (non-mandatory but good to have), PuTTy, PAgent, PGen PSftp
Overview of the Setup Process
Create a generic user to own the CVS Repositry and a group which all the CVS users will belong. Create a user for each developer and add them to the same group.
To create a server repository as the generic user the command is:
cvs -d /oracle/cvs/CVSROOT init
JDeveloper uses a private public key pair and SSH2 (other protocols available) to connect to the CVS. The key pair is generated in JDeveloper and the public key has to be manually added to the users authorized_keys file in the .ssh directory within the users home directory. The CVSROOT is the root directory of the CVS repository which is created by the CVS owner mentioned above.
Key Points About Using JDeveloper with CVS
Using JDeveloper with a CVS will break dependencies within the project which are normally enforced by JDeveloper in single user mode. When updating your project from the CVS the dependencies between objects are not enforced resulting in objects becoming out of sync. For instance a standard ADF BC View Object may consist of two files, its XML definition and View implementation file. It will also be referenced by one or more Application Module(s) and possibly a Viewlink. To prevent missing references and broken dependencies all the referenced / referencing objects must be included when committing and updating the CVS.
Open and close the project if there are dependency errors that do not seem to be correct.
CVS does not implement locking, it is the developers responsibility to make sure that the files they wish to work on are up to date. If two developers have worked on a file simultaneously a merge will be required when synchronising the CVS.
How do I know if my source is up to date with the CVS?
The key to getting the CVS JDev integration working properly is using the Pending Changes window effectively. Within this window are three tabs, Outgoing, Incoming and Candidates. Outgoing contains changed items which are not up to date with the CVS. Incoming displays items are new or the local copy is out of date with the CVS. Candidates are files not yet checked in with the CVS. The most important tab in the Pending Changes window is the Incoming Tab. Watch this one with care as incoming changes are NOT reflected in the Application Navigator unlike other file statuses. New files are not shown in the Application Navigator because they are not in the project but may be referenced by existing objects updated from the CVS. Using the Incoming tab is key to keeping the project in sync.
Minimising Pain and Suffering with CVS
Develop your model first and view second. If the model is not complete before development of the user interface it is worth finalising it first. The reason being is that the user interface (JSP's, pageDef's and Databindings.cpx) are a lot easier to fix than the data model when the project gets out of date and or needs to be merged. Most people will do this anyway, but it not always the case that the model is completed first.
Commit all changes regularly and especially before leaving at the end of the day. In the morning check the Incoming tab and update as necessary.
Occasionally perform a full checkout of your project from the CVS. This will cause any synchronisation issues to come to the surface and recover any missing files from backup if necessary.
Have the Li/Unix administrator include the CVS in the server backups.
Project Files and the CVS
The project JPR files often report conflicts which cannot be resolved by merging or committing changes. Fortunately JDeveloper is smart enough to pick up any stray/new files and add them to the project. Close and open the project and if all files are present force an unchanged commit of the project JPR file.
Bugs and Annoyances
View link files are continually 'touched' when the AM is updated resulting in them being in changed status continually even though they are not out of date with the CVS. This also clutters the Outgoing tab which is a pain if some of them are legitimately updated.
JDeveloper occasionally hangs when performing some CVS actions from the navigator. CVS actions issued from the Pending Changes window seem to be more reliable.
Occasionally some files are not recognised as an Object (such as a VO) and are displayed as their individual files in the Application Navigator. If this happens close and reopen your project and the object will reappear and its supporting files will be attached.
Further Reading
Oracle® Application Development Framework Developer’s Guide For Forms/4GL Developers (chapter 32 Working Productively in Teams) This manual can be downloaded from otn.oracle.com
Server: Linux OS, CVS Version 1.11.1p1
Client: Windows XP, JDeveloper 10.1.3.1 using ADF BC / Faces
Other tools (non-mandatory but good to have), PuTTy, PAgent, PGen PSftp
Overview of the Setup Process
Create a generic user to own the CVS Repositry and a group which all the CVS users will belong. Create a user for each developer and add them to the same group.
To create a server repository as the generic user the command is:
cvs -d /oracle/cvs/CVSROOT init
JDeveloper uses a private public key pair and SSH2 (other protocols available) to connect to the CVS. The key pair is generated in JDeveloper and the public key has to be manually added to the users authorized_keys file in the .ssh directory within the users home directory. The CVSROOT is the root directory of the CVS repository which is created by the CVS owner mentioned above.
Key Points About Using JDeveloper with CVS
Using JDeveloper with a CVS will break dependencies within the project which are normally enforced by JDeveloper in single user mode. When updating your project from the CVS the dependencies between objects are not enforced resulting in objects becoming out of sync. For instance a standard ADF BC View Object may consist of two files, its XML definition and View implementation file. It will also be referenced by one or more Application Module(s) and possibly a Viewlink. To prevent missing references and broken dependencies all the referenced / referencing objects must be included when committing and updating the CVS.
Open and close the project if there are dependency errors that do not seem to be correct.
CVS does not implement locking, it is the developers responsibility to make sure that the files they wish to work on are up to date. If two developers have worked on a file simultaneously a merge will be required when synchronising the CVS.
How do I know if my source is up to date with the CVS?
The key to getting the CVS JDev integration working properly is using the Pending Changes window effectively. Within this window are three tabs, Outgoing, Incoming and Candidates. Outgoing contains changed items which are not up to date with the CVS. Incoming displays items are new or the local copy is out of date with the CVS. Candidates are files not yet checked in with the CVS. The most important tab in the Pending Changes window is the Incoming Tab. Watch this one with care as incoming changes are NOT reflected in the Application Navigator unlike other file statuses. New files are not shown in the Application Navigator because they are not in the project but may be referenced by existing objects updated from the CVS. Using the Incoming tab is key to keeping the project in sync.
Minimising Pain and Suffering with CVS
Develop your model first and view second. If the model is not complete before development of the user interface it is worth finalising it first. The reason being is that the user interface (JSP's, pageDef's and Databindings.cpx) are a lot easier to fix than the data model when the project gets out of date and or needs to be merged. Most people will do this anyway, but it not always the case that the model is completed first.
Commit all changes regularly and especially before leaving at the end of the day. In the morning check the Incoming tab and update as necessary.
Occasionally perform a full checkout of your project from the CVS. This will cause any synchronisation issues to come to the surface and recover any missing files from backup if necessary.
Have the Li/Unix administrator include the CVS in the server backups.
Project Files and the CVS
The project JPR files often report conflicts which cannot be resolved by merging or committing changes. Fortunately JDeveloper is smart enough to pick up any stray/new files and add them to the project. Close and open the project and if all files are present force an unchanged commit of the project JPR file.
Bugs and Annoyances
View link files are continually 'touched' when the AM is updated resulting in them being in changed status continually even though they are not out of date with the CVS. This also clutters the Outgoing tab which is a pain if some of them are legitimately updated.
JDeveloper occasionally hangs when performing some CVS actions from the navigator. CVS actions issued from the Pending Changes window seem to be more reliable.
Occasionally some files are not recognised as an Object (such as a VO) and are displayed as their individual files in the Application Navigator. If this happens close and reopen your project and the object will reappear and its supporting files will be attached.
Further Reading
Oracle® Application Development Framework Developer’s Guide For Forms/4GL Developers (chapter 32 Working Productively in Teams) This manual can be downloaded from otn.oracle.com
ADF Faces – First Impressions
The much anticipated JDeveloper 10.1.3 was released at the end of January 2006 and definitely lived up to expectations among the JDeveloper community. The slick new interface boasts some really great features including significant enhancements in the code editor and overall feel of the IDE.
So what about Faces? ADF Faces is based on the JavaServer Faces industry standard framework. An open source implementation of JavaServer Faces called MyFaces has been [donated] to the Apache Foundation by Oracle.
The persistence layers offered by JDeveloper are ADF Business Components and Toplink. Oracle has released fully working example application called the SRDemo which is a simple service request system. The aim of the SRDemo is to solve most of the design woes faced by any developer starting out on green fields J2EE web application. SRDemo is written in ADF Faces (JSP) using TopLink and use J2EE container security for authentication and authorisation.
Why TopLink? TopLink is a POJO (plain old java object) based approach to creating an object-to-relational persistence layer. TopLink uses and EJB (Enterprise Java Bean) session façade and provides a full declarative (XML) persistence layer defined in what’s called a TopLink map. One really nice feature of TopLink is named queries; Named queries encourage the reuse of TopLink entities by exposing different operations on the entity (such as setting or changing conditions) by exposing methods through the Session Façade bean. I was impressed with TopLink, because it has some original and well implemented ideas. The POJO approach unpacks all the complexity which is hidden in ADF BC, which can be a bit daunting when starting out with the TopLink framework.
There are some significant improvements with ADF BC including some out-of-the-box goodies which either didn’t work or were a headache to implement in 10.1.2. Read-only view objects are great as well as dynamic view criteria. For those coming from an Oracle Forms or non-OO background, ADF BC is an easier transition than TopLink and is a mature and robust framework to go with.
The actual ADF Faces user interface can be implemented in two ways, a JSP (Java Server Pages) or a JSPX (XML Document). The faces lifecycle and faces-config.xml implements the controller layer providing the interaction between the model and view layers. ADF Faces provides an abundant set of UI components which give a consistent looking and rich user interface. Strong support for expression language makes binding components to the model a breeze. The backing bean and managed bean concept has also greatly simplified managing events.
So what about Faces? ADF Faces is based on the JavaServer Faces industry standard framework. An open source implementation of JavaServer Faces called MyFaces has been [donated] to the Apache Foundation by Oracle.
The persistence layers offered by JDeveloper are ADF Business Components and Toplink. Oracle has released fully working example application called the SRDemo which is a simple service request system. The aim of the SRDemo is to solve most of the design woes faced by any developer starting out on green fields J2EE web application. SRDemo is written in ADF Faces (JSP) using TopLink and use J2EE container security for authentication and authorisation.
Why TopLink? TopLink is a POJO (plain old java object) based approach to creating an object-to-relational persistence layer. TopLink uses and EJB (Enterprise Java Bean) session façade and provides a full declarative (XML) persistence layer defined in what’s called a TopLink map. One really nice feature of TopLink is named queries; Named queries encourage the reuse of TopLink entities by exposing different operations on the entity (such as setting or changing conditions) by exposing methods through the Session Façade bean. I was impressed with TopLink, because it has some original and well implemented ideas. The POJO approach unpacks all the complexity which is hidden in ADF BC, which can be a bit daunting when starting out with the TopLink framework.
There are some significant improvements with ADF BC including some out-of-the-box goodies which either didn’t work or were a headache to implement in 10.1.2. Read-only view objects are great as well as dynamic view criteria. For those coming from an Oracle Forms or non-OO background, ADF BC is an easier transition than TopLink and is a mature and robust framework to go with.
The actual ADF Faces user interface can be implemented in two ways, a JSP (Java Server Pages) or a JSPX (XML Document). The faces lifecycle and faces-config.xml implements the controller layer providing the interaction between the model and view layers. ADF Faces provides an abundant set of UI components which give a consistent looking and rich user interface. Strong support for expression language makes binding components to the model a breeze. The backing bean and managed bean concept has also greatly simplified managing events.
Running ADF applications in Debug mode
The ADF Lifecycle occasionally handles some exceptions and doesn't propagate them anywhere useful. This can be frustrating when you are encountering some strange behaviour but can't determine the cause.
When running the embedded OC4J container with JDeveloper you can enable debug level logging mode which will cause ADF to log all SQL statements, exceptions and other info to the Embedded OC4J containers log window in JDev.
to enable debug mode, right click on your ViewController project and select properties. Then select Profiles->Development->Runner nodes. In the java options field add the following:
-Djbo.debugoutput=console
When running the embedded OC4J container with JDeveloper you can enable debug level logging mode which will cause ADF to log all SQL statements, exceptions and other info to the Embedded OC4J containers log window in JDev.
to enable debug mode, right click on your ViewController project and select properties. Then select Profiles->Development->Runner nodes. In the java options field add the following:
-Djbo.debugoutput=console