|
Oracle® Application Development Framework Development Guidelines Manual
10g Release 2 (10.1.2) Part No. B14362-02 |
|
 Previous |
|
Oracle® Application Development Framework Development Guidelines Manual
10g Release 2 (10.1.2) Part No. B14362-02 |
|
|
Previous |
This appendix describes common problems that you might encounter when creating an Oracle ADF application and explains how to solve them. It contains the following topics:
This section describes common problems and solutions. It contains the following topics:
Previously Working Application Using ADF Business Components Starts Throwing JDBC Errors
Changes to ADF Business Components Parameters Have No Effect
ADF Business Components Deployed with Libraries Throw Exceptions
Unable to Use Browser Buttons to Navigate ADF Data Bound Web Pages
An application that previously successfully retrieved data suddenly starts throwing JDBC errors such as Connection Reset By Peer, Connection Closed, or Socket Reset By Peer.
Problem
The connections in the pool have become stale. This can happen for any of the following reasons:
The database was shut down or restarted without a corresponding restart of the JVM running the business components.
The connections were timed out by a firewall.
There were network problems.
Stale connections, when accessed, will throw errors.
Solution
If your ADF Business Components are deployed to Oracle Application Server 10g, you can set the parameter clean-available-connections-threshold to periodically clean up stale connections.
You have changed ADF Business Components runtime parameters, but the new parameters do not appear to have taken effect.
Problem
ADF Business Components runtime parameters can be specified in several separate locations. A location with a higher precedence is overriding your changes. Runtime properties can be specified in the following locations, in descending order of precedence:
The ADF application module configuration being used by the client application
Applet tags
-D flags passed to the JVM
The BC4J.properties file in the directory holding your business components
The /oracle/jbo/BC4J.properties resource
The /oracle/jbo/server/jboserver.properties resource
The /oracle/jbo/common/Diagnostic.properties resource
The ADF BC library's own defaults
Solution
Check the locations with higher precedence to ensure that they are not overriding your changes.
When your application attempts to access business components, it throws a class not found exception that mentions an ADF BC framework class. You can diagnose the cause of this problem by searching for the JAR file which contains the class mentioned in the exception.
Problem 1
Your application was designed against a newer version of the ADF BC libraries than is available on the server, and the old version does not contain some of the classes your application is expecting.
Solution 1
Use the ADF Runtime Installer to install a newer version of the ADF BC libraries on the server.
Problem 2
A JClient application has been distributed without the required libraries in its archive.
Solution 2
Redeploy the JClient application with the missing libraries.
Problem 3
The archive containing the needed class is not on the classpath.
Solution 3
Ensure that the OC4J classpath includes the archive containing the needed class.
You have deployed an application with ADF Business Components to a version of Oracle Application Server 10g with a different version of the ADF Business Components libraries installed. Even though you deployed the appropriate version of the libraries with your application, the application continues to throw exceptions as if it were attempting to run against the incorrect version.
Problem
The libraries installed on the application server appear earlier in the classpath than the appropriate libraries included in the application's EAR file.
Solution
Check the class loader hierarchy in the server.xml and orion-web.xml files to ensure that the libraries your application needs are loaded first. Ideally, you should avoid this problem by installing the latest version of the libraries using the ADF Runtime Installer.
Using the browser's Back button when navigating through row sets of an ADF data bound table yields unexpected results or throws a JBO error (JBO-33035). Using navigation within the application (such as Previous and Next links) works without any issues.
For example, suppose a page contains a table bound to data that returns 35 rows of query results. You've created an ADF iterator binding in your page's binding container and set the Range Size to 10, which means only 10 rows are displayed at a time.
The user takes the following steps:
Starts by looking at rows 1 - 10.
Uses the Next link in the application (which uses the ADF NextSet command).
Sees rows 11-20.
Uses the browser's Back button.
Sees rows 1-10 again. Because the user clicked the browser's Back button, the rows are retrieved from the browser's local page cache and not the application.
Uses the Next link in the application (which uses the ADF NextSet command) to go forward again.
The user will see one of two results, either of which is not expected:
If the page contains the ADF bindings State token, and you left the default setting of True for the Enable Token Validation property on the binding container, the user will see the JBO-33035 error.
If the page does not contain the ADF bindings State token, or if the developer has set the Enable Token Validation property on their binding container to False, then the user will see rows 21-30.
Problem
Both results occur because at step 6 the user pressed the browser's Back button to see the previous set of rows, instead of using the application's Previous link (ADF PreviousSet command). When using the browser to navigate, the page is retrieved from the browser's local page cache. Because of this, there is no interaction with the Web server. Therefore, the ADF iterator binding's current notion of the first row in the range and the current row in the row set remains unchanged. That is, the application still believes that at step 5, the current rows are 11-20 and not 1-10, as it has not received indication that the row set has changed.
The State token is by default added to a page and Enable Token Validation property is set to True when you drag and drop from the JDeveloper Data Control palette. The token is used to prevent duplicate form submission. When the Enable Token Validation property is set to True, the application validates during the prepareModel() phase of the ADF page lifecyle that the state of the iterators in the binding container is what your submitting web form expects them to be. Therefore if you do not change the property setting, when the user clicks the Next link in step 6, the application returns the error because during token validation it was expecting a different row set.
If the page does not contain the ADF bindings State token, or if the Enable Token Validation property is set to False, the application returns rows 21-30 because the last row set the application was aware of was 11-20.Had the user clicked the Previous link to go backward in step 4 instead of the browser's Back button, everything would have worked as expected.
Solution
The application should keep track of the current page number using a hidden field or in a URL parameter. The application can then use that current page number along with an appropriate event like NextPage, PreviousPage, or GotoPage, to calculate the next row set. This approach sets the next row set relative to the current set, irrespective of whether the user clicks the browser's Back button or the applications Previous link, as it is not dependent on the ADF iterator's current notion of the starting row in the range.
For more information, read the Generic Approach to Back-Button-Friendly Web Rowset Paging How-To on the JDeveloper section of the Oracle Technology Center at http://www.oracle.com/technology/products/jdev/tips/muench/paging/index.html.
You can find more solutions on Oracle MetaLink, http://metalink.oracle.com. If you do not find a solution for your problem, log a service request.
|
See Also:
|
