| Oracle® WebCenter Framework Developer's Guide 10g (10.1.3.2.0) Part Number B31074-05 |
|
|
View PDF |
| Oracle® WebCenter Framework Developer's Guide 10g (10.1.3.2.0) Part Number B31074-05 |
|
|
View PDF |
This appendix is intended to help users diagnose problems they encounter in building and deploying their WebCenter applications and their portlets. This appendix covers troubleshooting WebCenter applications and portlets. It contains the following topics:
This section describes common problems and solutions that may arise when working with Oracle WebCenter Framework. It is divided into the falling areas:
Section G.1.5, "Troubleshooting Portlets Built from Oracle ADF Faces Applications"
Section G.1.7, "Troubleshooting Application Life Cycle Issues"
This section describes problems and solutions for WebCenter applications.
The Credentials MBean, used for updating secure credentials in a deployed application, does not show up when you try to access it using Application Server Control Console.
Problem 1
The application is not running.
Solution 1
Start the application.
Problem 2
The application's web.xml file does not include the Oracle Application Development Framework (Oracle ADF) Authentication Servlet.
Solution 2
Ensure that the application's web.xml includes the Oracle ADF Authentication Servlet. See Section 12.5, "Updating Credentials in a Deployed Application" for information about how to do this.
Problem 3
The Oracle ADF Authentication Servlet was not loaded on startup.
Solution 3
Ensure that the Authentication Servlet is loaded on startup. See Section 12.5, "Updating Credentials in a Deployed Application" for information about how to do this
Problem 4
The oracle.extapp.runtime.jar file may not be available in your application classpath.
Solution 4
Ensure that the oracle.extapp.runtime.jar file is available in your application classpath.
You are running a large WebCenter application (multiple pages with multiple components on each page) and the application is failing with various errors.
Problem
The default memory size setting for some project templates is too small for large WebCenter applications. This issue can cause you application to fail with various errors.
Solution
Increase the MaxPermSize of your project to accommodate the larger WebCenter application as follows:
Go to Project Properties for the project.
Choose Run/Debug in the panel on the left.
Click the Edit button for Run Configurations.
In Java Options, enter the following:
-XX:MaxPermSize=256m
Click OK.
Click OK.
When you deploy your WebCenter application to a preseeded standalone OC4J, an error occurs indicating insufficient memory.
Problem
When you deploy your WebCenter application to a preseeded standalone OC4J, the following error occurs:
2007-03-05 17:17:47.140 INTERNAL_ERROR oracle.adf.share.config.ADFConfigImpl null date time java.lang.OutOfMemoryError: PermGen space date time java.lang.OutOfMemoryError: PermGen space date time java.lang.OutOfMemoryError: PermGen space date time java.lang.OutOfMemoryError: PermGen space date time java.lang.OutOfMemoryError: PermGen space date time java.lang.OutOfMemoryError: PermGen space
Before running the Predeployment tool, the permanent memory size used by the preseeded standalone OC4J needs to be increased, as a number of classes are loaded during the predeployment stage.
Solution
Ensure that you include the JVM argument to increase the permanent memory size. The argument string should include -XX:MaxPermSize=256m or higher to increase the permanent memory used for classloading, as shown in the following examples:
On Microsoft Windows:
cd OC4j_HOME\j2ee\home start java -server -XX:MAXPermSize=512M -Xmx256m -jar oc4j.jar
On UNIX/Linux (Bourne shell):
cd OC4J_HOME/j2ee/home java -server -XX:MAXPermSize=512M -Xmx256m -jar oc4j.jar &
This section describes common problems and solutions for portlets.
At design time in Oracle JDeveloper, you see the same portlets listed twice under the same producer in the Component Palette.
Problem
Two or more producers were given the same name when they were registered. Producers given the same name display only once on the Component Palette. So, if you register two producers and give them each the name MyProducer, then the name MyProducer displays only once on the Component Palette, and both producers' portlets are listed under the one instance. In addition to the duplication problem, this makes it difficult to determine which portlets come from which producer.
Solution
Edit the producer, and give it a unique name.
When you deploy the same application twice in the same OC4J instance under different names with different URLs for the same producer, the portlet customizations appear for only one of the applications and not the other.
Problem
Because the same application is deployed twice, both applications use producer and URL connections with the same names. Consequently, if the producer URLs are different between the two applications, then only one producer's customizations are available because connections.xml is loaded globally, not for each application. Therefore, whichever application is loaded first is the one whose connection entries are used. After that, the connections are pooled globally in memory and the second application to be accessed will use the first application's connection mappings. Thus, the second application's customizations are inaccessible because its producer URL is different from the first.
Solution
If you plan to deploy the same application multiple times to the same OC4J instance, then you must ensure that each application deployment uses the same connection mappings.
When you click the Update login information link on an external application portlet, you get the following error:
"javax.faces.el.MethodNotFoundException: processExtAppsCredentailEvent"
Problem
The Update login information link can be accessed only if you have created a Credential Provisioning page to store user credentials. Currently, there is no Credential Provisioning page within the project containing the external application portlet.
Solution
Create a Credential Provisioning page within the project containing the page with the portlet from an external application enabled producer. See Section 10.7.2.1, "Adding a Credential Provisioning Page" for the steps to be performed.
Your Oracle Application Server instance is up and running, but producers are not accessible.
Problem
If you chose the WebCenter Only option when installing, then your portlet producers are not running on the same HTTP port as the Oracle Application Server hosting your applications.
Solution
You can easily find the port on which your portlets are running by accessing the Welcome page of your Oracle Application Server:
http://myhost:port
Click the portlet links in the top right area of the page.
When you click the Update login information link on an external application portlet, the Credential Provisioning page is displayed with the following error:
1. External application ID was found to be null while rendering the Credential Provisioning page! 2. Cause: The credential page was probably run standalone or invoked from a portlet added from a producer that must be but has not been associated with an external application. 3. Action: The credential page must be invoked from the link in portlets added from producers associated with the external application. Running the credential page standalone is not supported.
Problem
You registered a producer that required external application authentication, but did not define and associate an external application with this producer. You then added a portlet from this producer on the page, which at run time, displayed a link to provision credentials. The error with the null external application ID implies the producer has not been associated with the external application to provision credentials.
Solution
For any producer requiring external application authentication, ensure that you associate the producer with the external application.
At run time, one of the portlets on the page displays the following error:
Unable to get portlet response (Internal Error) for portlet binding portlet_name_1
And on checking the log file, this error has the following cause listed:
oracle.adf.extapp.exception.ExtAppNotFoundException: The external application with ID /oracle/adf/externalApps/extApp243128437261430784.xml cannot be found.
Problem
An external application was accidentally or intentionally deleted but the producer it was associated with was not deregistered.
Solution
If the external application was deleted by accident, then create the relevant external application again and associate the producer with it.
If you intentionally deleted an external application, then make sure that you deregister the producer with which the application was associated. See Section 4.3.1.6, "Deregistering a Portlet Producer" for the steps to be performed.
When you access a portlet page from different URLs within the same session, OC4J loses the session and consequently you get errors accessing the portlet thereafter.
Problem
After accessing a page from different URLs, you receive a portlet unavailable error. For example, suppose that you first access a portlet page through a fully qualified URL, such as http://hostname.domain:port. Later, during the same session, you use a shortcut URL that omits the domain or port. Upon this second access, you receive portlet unavailable errors because the session has been lost.
Solution
Ensure that you specify URLs for portlet pages consistently. You should either fully qualify them all of the time or shortcut them (subtract domain and port) all of the time. You cannot mix and match the URL formats.
This section describes common problems and solutions for JPS (JSR 168) portlets.
When a consuming WebCenter application tries to assert security with WS-Security to the producer using a SAML token, the verification of the assertion fails because the system clocks of the two computers are not synchronized.
Problem
The system clock on the computer running the producer is ahead of the system clock on the computer running the WebCenter application trying to consume the producer. This situation results in the following:
A Portlet unavailable message appearing in the portlet markup.
The following error message appearing in the J2EE log (log.xml):
<MSG_TEXT>Assertion NOT_BEFORE_CONDITION invalid : Mon Nov 06 13:15:04 PST 2006arrival time : Mon Nov 06 13:14:59 PST 2006</MSG_TEXT>
The verification fails because the SAMLToken indicates the time when the message was generated and the assertion is not valid before that time.
Solution
Ensure that the clocks are synchronized or that the clock of the producer is behind the consuming WebCenter application's clock. Refer to your operating system documentation to determine the best way to check and set the system clock. Note that, if your producer and consumer are both deployed to the same Oracle Application Server instance, then they are running off the same clock and this problem will not occur.
You successfully registered your producer with WS Security, but the producer's portlets appear as unavailable on pages at run time.
Problem 1
You can have inadvertently entered incorrect values (for example, for Issuer) in the WSRP Producer Registration Wizard when you registered the portlet. The wizard cannot actually validate the security information, hence the registration can complete successfully, but the portlets are inaccessible at run time due to some incorrect security values.
Solution 1
Deregister the portlet and then reregister it ensuring that you have the correct values specified, particularly for things like Issuer.
Problem 2
Your keystore path was not configured correctly to use an absolute path, or your Oracle Containers for J2EE (OC4J) instance was not restarted after the configuration. Your log file (typically located in ORACLE_HOME/j2ee/OC4J_WebCenter/log/OC4J_WebCenter_default_group_1/oc4j) contains WARNING level log messages like the following:
<MSG_TEXT> Couldn't resolve kestore path : /ASINSTALL10132/j2ee/OC4J_WebCenter/META-INF/portal.jks </MSG_TEXT> <MSG_TEXT> Invalid keystore path META-INF/portal.jks </MSG_TEXT>
Solution 2
Perform the steps in Updating the Keystore Path under Section 10.10.3, "Configuring the Consumer".
Your JPS portlet producer EAR file fails to convert to a WSRP producer EAR file.
Problem
When attempting to convert a JPS portlet producer EAR file into a WSRP producer EAR file, the following exception is thrown:
Exception in thread "main" oracle.portlet.server.containerimpl.deploy.PortletDeployException: A network error occurred during XML transformation. Check your network, firewall and proxy settings.
Solution
For JPS-compliant portlets developed with servlet version 2.3, you must specify Web proxies using a command of the form:
java -Dhttp.proxyHost=proxy_host -Dhttp.proxyPort=proxy_port -jar wsrp-predeploy.jar source_ear_file targeted_ear_file
Portlets are throwing a Portlet unavailable error because their producer has a different preference store path than the rest of the producers in the OC4J instance.
Problem
JPS portlets for a particular producer are unavailable even though portlets for other producers within the same OC4J instance are available.
Solution
The preference store path, oracle/portal/wsrp/server/fileStoreRoot, in web.xml must be the same for all producers deployed to the same OC4J instance. If you simply let the preference store location default rather than explicitly specifying it, then all producers will use portletdata as the default location. If you explicitly specify a path for any one of the producers in the OC4J instance, then you must ensure that all of the other producers in that same instance use that same path. Otherwise, some portlets will be unavailable.
The JPS portlet that is created by using JDeveloper does not work on Pluto.
Problem
When you try to deploy the JPS portlet on Pluto, the portlet throws an error.
Solution
Perform the following steps in the wizard to get the JPS portlets working on Pluto:
The portlet mode JSPs must be changed to be created under the WEB-INF folder.
In the newly created web.xml, remove all attributes except for version="2.4" in the <web-app> root. This applies only if you have selected the Web Application version as Servlet 2.4\JSP 2.0(J2EE 1.4) while creating the JSR 168 portlet.
This section describes common problems and solutions for PDK-Java portlets.
Your portlet displayed the following message when accessed:
##REDIRECT##<URL>
Problem
Your portlet probably issued a redirect call to some URL immediately upon switching to a particular portlet mode. Portlets cannot issue redirects except as the result of a user action within the portlet, such as a form post.
Solution
Rewrite your portlet to avoid this behavior.
When you switch to a full page portlet mode (for example, Edit mode), images are broken or missing.
Problem 1
You are running the producer on a WebCenter Suite OC4J instance and the portlet is running on an Oracle ADF page. If the page markup for images contains a relative URL, like /images/image_name, then the most likely cause of the problem is that the images are not present on the ADFP servlet.
If the markup contains a full URL to the image, then the most likely cause of the problem is that the producer is not configured to use resource proxying. In this case, the URL refers directly to a producer, which cannot be directly accessible to the user, rather than through the ADFP servlet. If resource proxying is used, the image URL points to the resource proxy servlet.
Solution 1
Perform the following actions:
Make sure the resource servlet configuration details are included in the web.xml for the producer application and bounce the producer if you must add them. You should now see full URLs for each image tag src attribute. See Section A.1.1.9.2, "Redeploying PDK-Java Producers from OracleAS Portal".
Get the images zip file from the Oracle Technology Network and unzip it inside the ADFP servlet.
Problem 2
You are running the producer on a WebCenter Suite OC4J instance and the portlet is running on an Oracle Application Server Portal (OracleAS Portal) page. In this case, the most likely problem is that you do not have the resource proxy properly configured.
Solution 2
Make sure the resource servlet configuration details are included in the web.xml for the producer application and bounce the producer if you must add them. You should now see full URLs for each image tag src attribute. See Section A.1.1.9.1, "Consuming a Portlet from OracleAS Portal".
Problem
A PDK-Java portlet fails when the resource for any portlet mode is a JSP whose file name contains non-ASCII characters.
Solution
Rename the JSP portlet mode resources to use ASCII characters only.
PDK-Java producers cannot have multibyte characters in their Service IDs.
Problem
Registration fails and the producer test page returns an error:
oracle.webdb.provider.v2.utils.soap.SOAPException: Can't read deployment properties for service: ??????
Solution
Rebuild the producer and provide a Service ID without multibyte characters.
Problem
Images accessed by a relative URL cannot be found in an Oracle WebCenter Framework environment as they were in an OracleAS Portal environment.
Solution
You can resolve this issue in one of two ways:
Add the images to the Oracle WebCenter Framework servlet so that the relative URLs in image markup will point to them.
Use UrlUtils.constructResourceURL to generate and render an absolute link that will refer either to a proxy for the resource (if resource proxying has been set up for the producer) or directly to the image resource on the Web producer. See Section 18.1.2.4, "Internal/Resource Links" for more information about Web producer resource proxying.
This section describes common problems and solutions that you may encounter while you code Oracle ADF pages that you can later choose to publish as portlets, or while running portlets built from Oracle ADF Faces applications.
When you try to portletize your Oracle ADF page, you get an error and are unable to proceed.
Problem
Your application was not built using a Web Application template that employs JSF.
Solution
Ensure that your application is built with one of the Web Application templates that employs JSF.
When you run your portlet, you get errors because the images and resources could not be located.
Problem
The paths to these files are not specified to be relative to the Web application context root.
Solution
Specify the image and resource locations relative to the web-app-context-root. Do not use relative (../) path notation.
When running a portlet, if you navigate away from the page and return to it again, then you may find that the portlet state is lost. That is, the private portlet parameter settings you made earlier are lost.
Problem
For Oracle ADF Faces applications portlets, the state must be saved on the server side. By default, Oracle ADF Faces is client-managed.
Solution
You must explicitly configure the application to use server-side state management by defining the following in your web.xml:
<context-param> <param-name>javax.faces.state_saving_method</param-name> <param-value>server</param-value> </context-param>
When testing the producer's Web Services Description Language (WSDL) URL in development environment, you get an error.
Problem
The OC4J instance was not bounced.
Solution
Restart OC4J before testing the WSDL URL in a browser.
When WSRP portlets are deployed to an OC4J instance in Oracle Application Server and tested in a browser, 404 error appears.
Problem
WSRP portlets were deployed to the home instance of OC4J in Oracle Application Server, which did not have a WSRP container.
Solution
Deploy WSRP portlets to the OC4J_Portal instance of Oracle Application Server instead of the home instance.
Unable to navigate to another page from your portlet.
Problem
You may have used response.sendRedirect("") to navigate to another page.
Solution
To work properly in a portlet environment, you must implement navigation with navigation rules in faces-config.xml.
You may experience problems when trying to render your JSF portlet on a page.
Problem
The page definition, pageDef.xml, must have the doExecuteWithParams executable's Refresh attribute set to renderModel rather than prepareModel.
Solution
Set the Refresh attribute to renderModel as shown in the following example:
<invokeAction id="doExecuteWithParams" Binds="ExecuteWithParams"
Refresh="renderModel" RefreshCondition="${param.id != null}"/>
You get a missing class error when you update the portlet deployment descriptor, portlet.xml, and then try to deploy the application.
Problem
The proper classes are not defined in portlet.xml. Your portlet.xml file may not be configured to match the filters specified in your web.xml file
Solution
Specify the classes using the BridgeLifecycleListeners attribute in your portlet.xml file as follows:
<init-param> <name>BridgeLifecycleListeners</name> <value>listener_class_n[,listener_class_n+1,...]</value> </init-param>
For example, suppose that your application includes the following code excerpt in its web.xml:
<filter> <filter-name>adfFaces</filter-name> <filter-class>oracle.adf.view.faces.webapp.AdfFacesFilter</filter-class> </filter>
You would then must include the following class in your portlet.xml:
<init-param>
<name>BridgeLifecycleListeners</name>
<value>oracle.portlet.server.bridges.jsf.adf.ADFFacesBridgeLifecycleListener
</value>
</init-param>
Similarly, suppose that ADFBindingFilter is defined in web.xml as follows:
<filter> <filter-name>adfBindings</filter-name> <filter-class>oracle.adf.model.servlet.ADFBindingFilter</filter-class> </filter>
You would then must include the following class in your portlet.xml:
<init-param>
<name>BridgeLifecycleListeners</name>
<value>oracle.portlet.server.bridges.jsf.adf.
BindingFacesBridgeLifecycleListener</value>
</init-param>
When turning a JSF application into a portlet using the JSF portlet bridge, packaging, deploying, and consuming the portlet, the portlet displays the following error message:
Portlet Unavailable
Problem
Your application is not using Oracle ADF binding, but the portlet.xml contains BindingFacesBridgeLifecycleListener. You probably have something similar to the following in your portlet.xml:
<init-param>
<name>BridgeLifecycleListeners</name>
<value>
oracle.portlet.server.bridges.jsf.adf.ADFFacesBridgeLifecycleListener,
oracle.portlet.server.bridges.jsf.adf.BindingFacesBridgeLifecycleListener
</value>
</init-param>
Solution
Ensure that your portlet.xml does not make reference to BindingFacesBridgeLifecycleListener. It should look similar to the following:
<init-param>
<name>BridgeLifecycleListeners</name>
<value>
oracle.portlet.server.bridges.jsf.adf.ADFFacesBridgeLifecycleListener
</value>
</init-param>
Notice the omission of BindingFacesBridgeLifecycleListener in this case.
This section provides information to help you troubleshoot problems you may encounter while using OmniPortlet.
You are not able to define the OmniPortlet at run time by using the Define link.
Problem
OmniPortlet only supports a RenderPortletInIFrame value of true. This means that OmniPortlet must be rendered within an IFrame and therefore, the OmniPortlet property, RenderPortletInIFrame, must be set to true. In the Property Inspector, the RenderPortletInIFrame property is available under Display Options.
Currently, the RenderPortletInIFrame property has a value of false and, as a result, when you click the Define link at run time, the Type tab may not display and you cannot proceed with defining the OmniPortlet.
Solution
You can choose Customize from the Action list to define OmniPortlet, or select the OmniPortlet in the Structure pane in Oracle JDeveloper, and in the Property Inspector, set RenderPortletInIFrame to true.
This section describes common problems and solutions you may encounter when deploying or predeploying your WebCenter application or its components.
The Predeployment tool cannot unlock the temporary directory to create temporary files and therefore it fails.
Problem
When you abnormally terminate the Predeployment tool (for example, by pressing Ctl-C), it may have some temporary files locked and, on MS Windows, the locks may be transferred to the invoking cmd process. Hence, the locks on the temporary files are not released and, when you try to run the Predeployment tool again, the locks prevent it from creating the necessary temporary files for the operation. The following error is thrown:
Unable to create temporary work area
Solution
Invoke the Windows Task Manager to find the invoking cmd process and terminate it.
When deploying the application to an EAR file in Oracle JDeveloper, you receive an error similar to the following in the deployment console.
Error during export
Problem
One of the applications portlet producers could be unavailable.
Solution
If the producer is down, then you must restart it. If the producer is up and you still receive this error, then you should contact Oracle Support with the exception stack from the Oracle JDeveloper log window.
After specifying all the settings requested, the Predeployment tool failed with the error:
Unable to find MDS Repository for Portlet Producers
Problem
You may not have created the generic EAR file with the WebCenter Application WAR deployment profile. You may have inadvertently used the WAR File deployment profile.
Solution
Recreate the deployment profile being sure to choose WebCenter Application WAR. Regenerate the generic EAR file using the corrected deployment profile.
After specifying all the settings requested, the Predeployment tool failed with one of the following errors:
Unexpected PortletException Error during import
Problem
The target producer may be down.
Solution
Check the target producer to make sure it is up and running. If it is down, then restart it.
The application runs fine in Oracle JDeveloper's embedded OC4J, but, after deploying to an OC4J instance outside of Oracle JDeveloper, all of the portlets on the page show the error:
No object with ID /oracle/adf/portlet/...
Problem
The Oracle Metadata Services (MDS) directory containing the portlets' metadata cannot be found.
Solution
When you create the generic deployment descriptor for the application in Oracle JDeveloper, make sure you associate the descriptor with a target platform (for example, OC4J).
When attempting to run the page, the browser shows either one of the following errors:
Servlet error: An exception occurred. The current application deployment descriptors do not allow ... MDSRuntimeException: No metadata found for metadata object .../*.jspx
Problem
These errors could be caused by any number of problems:
This is an Oracle ADF Faces page and your URL do not invoke the faces servlet.
adf-config.xml contains an invalid metadata path specification.
web.xml contains an invalid oracle.mds.web-app-root specification.
The view documents do not exist at the specified location.
The application does not contain orion-application.xml.
Solution
Check all of the following:
Make sure your URL references the faces servlet. Typically, it should look something like the following:
<protocol>://<host>:<port>/<context root>/faces/<jspx document path>
In the MDS directory, the location of the view document should be:
metadata-path_in_adf-config.xml/oracle.mds.web-app-root_in_web.xml/ view_document_path_after_/faces_in_the_URL
Check to make sure the settings in adf-config.xml and web.xml point to a valid path and the documents do exist in the specified path.
Note:
When running from Oracle JDeveloper, themetadata-path entry in adf-config could be a relative path. If so, it's relative to the location of adf-config.xml.For OC4J, the application requires orion-application.xml. Otherwise, adf-config.xml cannot be located. If you cannot see an orion-application.xml in the deployed application's META-INF directory, then make sure your application deployment descriptor in Oracle JDeveloper is associated with an OC4J/Oracle Application Server connection for the platform setting.
If your MDS path contains Western European characters, such as an umlaut over a vowel, then the path generated by the Predeployment tool becomes garbled.
Problem
After predeployment, the MDS path in adf-config.xml is garbled and unusable. This corrupted path will cause errors in any attempted deployment of your application.
Solution
Check the value of your code page by executing chcp at a command prompt. If the value returned is a DOS code page for the language (for example, 850), then you must change it to a Windows code page (for example, 1252). To change the code page, you execute chcp code_page_number at the command prompt. For example:
chcp 1252
Oracle WebCenter Framework can record information related to the requests they receive in log files. This section provides instructions to diagnose run time and design time problems and covers the following topics:
Oracle WebCenter Framework logging is based upon the JDK logging framework, which includes the JDK logging Application Programming Interface (API). JDK logging has a standard API, java.util.logging.Logger, that has been available in the Java Platform since JDK 1.4. To enhance the basic JDK logging, the Oracle Diagnostic Logging (ODL) framework provides support for extended, Oracle-specific message formatting and configuration through Extensible markup Language (XML) files. You can choose to use JDK logging by itself, with no ODL enhancements, or you can use the JDK API to log diagnostic messages and ODL to provide enhanced output formatting and configuration through XML files. Both methods are described in the sections that follow.
Before you configure logging, you must know about the following:
The same logging framework is used for both design time and run time, hence the only difference in configuration is that, in design time (Oracle JDeveloper), you must ensure that jdev.conf points to the correct logging configuration file. This step is called out where appropriate in the procedures that follow.
You can configure logging in either of the following ways. The first method provides you with enhanced ODL output. The second method provides only the standard JDK logging output. In all cases, though, the basic message bodies provide the same information.
Loggers provide diagnostic messages for particular components or areas of your WebCenter application. Table G-1 lists the available loggers and what they track. Note that the loggers adhere to the standard, hierarchical naming scheme. Hence, you can specify a parent logger, such as oracle.portlet, to turn on logging for all of its children, oracle.portlet.binding and oracle.portlet.client.
Table G-1 Available Loggers for Oracle WebCenter Framework
| Logger Name | Description |
|---|---|
oracle.portlet |
Provides logging for both portlet bindings and portlet run time. |
oracle.portlet.binding |
Provides logging for portlet bindings. |
oracle.portlet.client |
Provides logging for portlet run time. |
oracle.portlet.management.mbean |
Provides logging for the portlet MBean. |
oracle.portal |
Provides logging for portal server components, including WSRP, PDK-Java, Omniportlet, and Web Clipping. |
oracle.vcr |
Provides logging for all Java Content Repository (JCR)-related functions. |
oracle.vcr.datacontrol |
Provides logging for JCR data controls. |
oracle.vcr.jam |
Provides logging for the JCR Adapter Manager. |
oracle.vcr.share |
Provides logging for the JCR run time shared package. |
oracle.vcr.dav |
Provides logging for the JCR Get Handler. |
oracle.vcr.adapter |
Provides logging for JCR adapters. |
oracle.adfdtinternal.config |
Provides logging for configuring an application workspace in Oracle JDeveloper for a WebCenter application. |
oracle.adfdtinternal.model.portlet |
Provides logging for the portlet design time extension. |
oracle.adfinternal.model.portlet |
Provides logging for the portlet design time model. |
oracle.adfinternal.view.faces.renderkit.html.customizable |
Provides logging for customizable components. |
oracle.adfinternal.view.faces.ui.action |
Provides logging for customizable components. |
oracle.adf.share.security logger |
Provides logging for Oracle ADF security. |
oracle.adf.extapp |
Provides logging for external application and credential mapping service. |
oracle.adf.richtextportlet |
Provides logging for the Rich Text Portlet. |
By specifying the level of logging, you can choose the amount of log information to record. The default Java log levels and their ODL counterparts are listed in Table G-2. You can use the JDK logging levels in both JDK and ODL logging configuration files. The ODL levels can only be used in ODL logging configuration files.
Table G-2 Logging Scope
| JDK Logging Level | ODL Logging Level | Description |
|---|---|---|
|
SEVERE+100Foot 1 (only specified in code) |
INTERNAL_ERROR |
Log unexpected errors or exceptions. These errors usually imply bugs in the code and customers must call support to report the problem. |
|
SEVERE |
ERROR:1 |
Log system errors requiring attention from the system administrator. |
|
WARNING |
WARNING:1 |
Log actions or conditions discovered that should be reviewed and may require an action before an error occurs. |
|
INFO |
NOTIFICATION:1 |
Default logging level. Log normal actions or events. This could be a user operation, such as login completed, or an automatic operation, such as a log file rotation. |
|
CONFIG |
NOTIFICATION:16 |
Log configuration-related messages or problems. |
|
FINE |
TRACE:1 |
Log trace or debug messages used for debugging or performance monitoring. Typically includes detailed event data. |
|
FINER |
TRACE:16 |
Log fairly detailed trace or debug messages. |
|
FINEST |
TRACE:32 |
Log highly detailed trace or debug messages. |
Footnote 1 SEVERE+100 can only be used within code. You cannot use it in the configuration files.
For more information about JDK logging levels, see:
http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Level.html
To configure logging that takes advantage of ODL features, you use the j2ee-logging.xml file that is installed in the ORACLE_HOME/j2ee/oc4j_instance/config directory.
The ODL framework provides plug-in components that complement the standard Java framework to automatically integrate log data with Oracle log analysis tools. In the ODL framework, log files are formatted in plain text or XML, enabling them to be more easily parsed and reused by other Oracle Application Server and custom developed components.
The oracle.core.ojdl.logging package includes a Handler class, ODLHandler, which generates the Logger output in either XML-based ODL format or plain text. To enable Java Loggers to output log messages in the ODL format, each logger must be mapped to ODLHandler. This mapping is managed through j2ee-logging.xml. See Oracle Containers for J2EE Developer's Guide for detailed information about configuring Java loggers to use the ODL framework. For general information about j2ee-logging.xml, see Oracle Application Development Framework Developer's Guide.
To configure logging information by using the j2ee-logging.xml file and to output log messages in the ODL format, perform the following steps:
Navigate to the ORACLE_HOME/j2ee/home/config directory and open the j2ee-logging.xml file in an editor. Note that if the component is deployed to an instance other than the home instance, then you will must substitute for home the path accordingly. For example, the path for an OC4J instance called OC4J_WebCenter would be ORACLE_HOME/j2ee/OC4J_WebCenter/config.
Choose whether you want log output in XML or plain text format. The default format is XML.
Note:
Inj2ee-logging.xml, you can also change other log properties, such as the location of the log file. For example:
<property name='path' value='C:/TEMP/log/'/>
Example G-1 provides a sample j2ee-logging.xml fragment that configures logging for XML output.
Example G-1 j2ee-logging.xml for XML Logging Output
<logging_configuration>
<log_handlers>
...
<log_handler name='ptlLoggingHandler'
class='oracle.core.ojdl.logging.ODLHandlerFactory'>
<property name='path' value='C:/TEMP/log/'/>
<property name='maxFileSize' value='104857600'/>
<property name='maxLogSize' value='1048576000'/>
</log_handler>
</log_handlers>
<loggers>
...
<logger name='oracle.adfinternal.model.portlet'
level='FINER'
useParentHandlers='false'>
<handler name='ptlLoggingHandler'/>
</logger>
<logger name='oracle.adfdtinternal.model.portlet'
level='FINER'
useParentHandlers='false'>
<handler name='ptlLoggingHandler'/>
</logger>
<logger name='oracle.portlet.client'
level='FINE'
useParentHandlers='false'>
<handler name='ptlLoggingHandler'/>
</logger>
</loggers>
</logging_configuration>
Example G-2 provides a sample j2ee-logging.xml fragment that configures logging for plain text output. Note the lines in bold. The first two bold lines configure the log for plain text output. The second two bold lines reduce the clutter, which is typical when you are planning to view the output in plain text format.
Example G-2 j2ee-logging.xml for Plain Text Output
<logging_configuration>
<log_handlers>
...
<log_handler name='ptlLoggingHandler'
class='oracle.core.ojdl.logging.ODLHandlerFactory'>
<property name='path' value='C:/TEMP/log/diag.log'/>
<property name='maxFileSize' value='104857600'/>
<property name='maxLogSize' value='1048576000'/>
<property name='format' value='ODL-Text'/>
<property name='useSourceClassAndMethod' value='true'/>
<property name='useDefaultAttributes' value='false'/>
</log_handler>
</log_handlers>
<loggers>
...
<logger name='oracle.adfinternal.model.portlet'
level='FINER'
useParentHandlers='false'>
<handler name='ptlLoggingHandler'/>
</logger>
<logger name='oracle.adfdtinternal.model.portlet'
level='FINER'
useParentHandlers='false'>
<handler name='ptlLoggingHandler'/>
</logger>
<logger name='oracle.portlet.client'
level='FINE'
useParentHandlers='false'>
<handler name='ptlLoggingHandler'/>
</logger>
</loggers>
</logging_configuration>
Save the j2ee-logging.xml file.
In the design time environment, you must point to j2ee-logging.xml for logger settings by updating JDEV_HOME/jdev/bin/jdev.conf as follows:
# Add OJDL jars in the classpath
AddJavaLibFile ../../BC4J/lib/adfshare.jar
AddJavaLibFile ../../diagnostics/lib/ojdl.jar
# Add logger configuration for diagnostics logging
AddVMOption
-Djava.util.logging.config.class=oracle.core.ojdl.logging.LoggingConfiguration
AddVMOption -Doracle.core.ojdl.logging.config.file=
JDEV_HOME/j2ee/home/config/j2ee-logging.xml
Restart the Oracle Application Server.
The log file will be generated in the location you specified in j2ee-logging.xml file, that is, in C:/TEMP/log/diag.log. You can also view the log file in Oracle Enterprise Manager 10g.
Note:
In the design time environment, instead of using the defaultj2ee-logging.xml file, you can create a custom properties file and use that file to specify logging configuration. However, if you use a custom properties file, then you must edit the <JDEV_HOME>/jdev/bin/jdev.conf file to point to the new properties file.To configure standard JDK logging, you can use the default logging properties file, jdk/jre/lib/logging.properties, and perform the following steps:
Navigate to the jdk/jre/lib directory and open logging.properties in an editor.
Under the Global properties section, specify the log handler class to be used. This determines whether log information must be output to the console or recorded in a log file. By default, console output is configured and the entry appears as follows:
handlers= java.util.logging.ConsoleHandler
To enable file output also, uncomment the FileHandler entry, which appears as follows:
#handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
Specify the global logging level by setting level under the Global properties section. This controls the type of events that must be logged. The default global logging level is INFO. Supported log levels are described in Section G.2.2.2, "Logging Levels".
Under the Handler specific properties section, specify values for the following:
java.util.logging.FileHandler.pattern: Specify a name and location for the log file
Note:
At design time, if you specify theFileHandler pattern as portlet.log, then the log file will be generated under the <JDev_install>/jdev/bin directory.
See the following location for information about FileHandler patterns to be used for Unix and Windows Platforms:
http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/FileHandler.html
java.util.logging.ConsoleHandler.level: Specify the logging level, which limits the message that is printed to the console
Under the Facility specific properties section, you can specify any extra controls for each logger as shown in the following examples:
oracle.adfinternal.model.portlet.level = FINER oracle.adfdtinternal.model.portlet.level = FINER oracle.portlet.client.level = FINE oracle.vcr.datacontrol.level = FINE oracle.vcr.adapter.fs.level = FINE
Save the logging.properties file.
A sample configuration in logging.properties file is shown in Example G-3, with new settings shown in bold text.
Example G-3 Sample Configuration in the logging.properties File
# "handlers" specifies a comma separated list of log Handler # classes. These handlers will be installed during VM startup. # Note that these classes must be on the system classpath. # By default we only configure a ConsoleHandler, which will only # show messages at the INFO and above levels. handlers= java.util.logging.ConsoleHandler # To also add the FileHandler, use the following line instead. handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler # Default global logging level. .level= INFO ############################################################ # Handler specific properties. # Describes specific configuration info for Handlers. ############################################################ # default file output is in user's home directory. java.util.logging.FileHandler.pattern = %h/portlet%u.log java.util.logging.FileHandler.limit = 50000 java.util.logging.FileHandler.count = 1 java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter # Limit the message that are printed on the console to INFO and above. java.util.logging.ConsoleHandler.level = INFO java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter ############################################################ # Facility specific properties. # Provides extra control for each logger. ############################################################ oracle.adfinternal.model.portlet.level = FINER oracle.adfdtinternal.model.portlet.level = FINER oracle.portlet.client.level = FINE
At design time, instead of using the default logging.properties file, you can create a custom properties file and use that file to specify standard JDK logging configuration. However, if you use a custom properties file, you must edit the JDEV_HOME/jdev/bin/jdev.conf file and update the following entry to point to the new properties file:
AddVMOption -Djava.util.logging.config.file=<path and name of the properties file>
For example, you can create a custom file called portlet-logging.properties under the /tmp directory. Copy the content from the default logging.properties file to the new file and update configuration information as described in Section G.2.2.4, "Configuring Logging Through the Default JDK Logging Properties File". After this, to point to portlet-logging.properties for logger settings, you must update the JDEV_HOME/jdev/bin/jdev.conf file as follows:
AddVMOption -Djava.util.logging.config.file=/tmp/portlet-logging.properties
Logger settings are now picked up from the portlet-logging.properties file that you created.
For information about how to configure custom JDK logger properties files, see
You can open the log file from whatever location you specified in the configuration file using an appropriate editor or viewer. If you are using Oracle JDeveloper, then you can view the diagnostic output in the Oracle JDeveloper log window. The default location of the Oracle JDeveloper log file is JDEV_HOME/jdev/bin/portlet.log.
You can find more solutions on Oracle MetaLink at
If you do not find a solution for your problem, then log a service request.
Contact Oracle Support Services.
See Also:
Oracle Application Server Release Notes for Microsoft Windows, available on Oracle Technology Network (OTN)http://www.oracle.com/technology/documentation/index.html