FAQ #7 - How to configure ADF diagnostics logging in standalone WLS using JDeveloper 11g R1

Introduction

In FAQ #6 - How to fine tune ADF diagnostics logging in JDeveloper 11g R1 we’ve seen how to configure diagnostics logging for the integrated WLS in JDeveloper. Configuration of diagnostics logging for the standalone WLS can be done in a similar fashion. Let’s take a look.


Main Theme

For some basic information regarding ADF diagnostics logging refer to FAQ #6 - How to fine tune ADF diagnostics logging in JDeveloper 11g R1. We will repeat some of the introductory information here as it applies to the standalone WLS.

ADF diagnostics logging is controlled via the usage of the jbo.debugoutput parameter. Using this parameter with the console value, i.e. -Djbo.debugoutput=console, produces diagnostic logs directly in the JDeveloper Log console window when deploying and running an application on the integrated WLS in JDeveloper. When set to the ADFLogger value, diagnostics are routed through the standard J2SE Logging API and are controlled through the logging.xml configuration file. For the standalone WLS this file can be found in the %MIDDLEWARE_HOME%\user_projects\domains\%DOMAIN_NAME%\config\fmwconfig\servers\%SERVER_NAME% for the Windows operating systems.

%MIDDLEWARE_HOME% is the installation directory of the standalone WLS, %DOMAIN_NAME% and %SERVER_NAME% are the WLS domain and server that we are configuring. For information on how to setup the standalone WLS, take a look at FAQ #1 – How to configue the standalone WebLogic server for deploying ADF applications from JDeveloper 11g R1 (11.1.1.2.0).

Let's locate the logging.xml file in the above directory and drag and drop it on JDeveloper.

JDeveloper will open the file and display it in the Overview tab.

In order to produce detailed diagnostic logs for the ADF BC oracle.jbo classes, we need to set the log Level to at least FINE. Let's set it to the most detailed level FINEST - TRACE:32 if using ODL Log Levels - for the oracle.jbo logger. Also let's ensure that the odl-handler log handler is configured to generate diagnostics for all log levels. To verify, select the odl-handler in the structure window and ensure that the level attribute is set to ALL.

Lastly we need to specify the -Djbo.debugoutput=adflogger -Djbo.adflogger.level=FINEST parameters when starting the standalone WLS, so let's open the setDomainEnv.cmd domain environment settings script in the %MIDDLEWARE_HOME%\user_projects\domains\%DOMAIN_NAME%\bin directory and add the following line:

set JAVA_OPTIONS=%JAVA_OPTIONS% -Djbo.debugoutput=adflogger -Djbo.adflogger.level=FINEST

That's all there is to it! Now let's start the standalone WLS, deploy and run our application. Take a look at FAQ #3 - How to deploy an ADF application on a standalone WebLogic server directly from JDeveloper for information on how to deploy an application onto WLS.

You should see those familiar ADF BC oracle.jbo diagnostic logs come flying in the WLS log window!

Conclusion

ADF Diagnostics Logging for the standalone WLS is done through the logging.xml file in a similar fashion as for the integrated WLS. It is a powerful feature that allows us to fine tune the log generation of our application and much more.

Until the next time, keep on JDeveloping!

FAQ #6 - How to fine tune ADF diagnostics logging in JDeveloper 11g R1

Introduction

FAQ #2 – How to enable debug information generation for an ADF BC project demonstrated a simple rather known technique to generate diagnostics logging in the JDeveloper Log window when testing an ADF BC application module with the BC tester. This barely scratched the surface of what is actually available in JDeveloper concerning diagnostics logging.

Main Theme

ADF diagnostics logging is controlled via the usage of the jbo.debugoutput parameter. Using this parameter with the console value, i.e. -Djbo.debugoutput=console, produces diagnostic logs directly in the JDeveloper Log window. When set to the ADFLogger value, diagnostics are routed through the standard J2SE Logging API and is controlled through the logging.xml configuration file. For the integrated WebLogic server this file can be found the C:\Users\username\AppData\Roaming\JDeveloper\ system11.1.1.x.x.x.x\DefaultDomain\config\fmwconfig\servers\DefaultServer for Windows 7 and in the C:\Documents and Settings\username \ApplicationData\JDeveloper\system11.1.1.x.x.x.x \DefaultDomain\config\fmwconfig\servers\DefaultServer for older Windows versions.

Let’s take a closer look:

In the Application Server Navigator – use View | Application Server Navigator to display if needed – expand the Application Servers node and right-click on the IntegratedWebLogicServer connection. This connection is generated automatically by JDeveloper for accessing the integrated WebLogic server. From the context menu select Configure Oracle Diagnostic Logging for “IntegratedWebLogicServer”.

JDeveloper opens the logging.xml diagnostics logging configuration file and displays it in the Overview tab. In the Loggers section expand the Root Logger (default) node to display all the loggers that are declared.

The three columns in the Overview tab display the Name of the logger, the diagnostics logging Level for the logger and any log handlers associated with the logger. The Name of the logger represents the Java package that will be generating the specific diagnostics logs. The Level value specifies the granularity of the diagnostic logs to be generated and it is defined either in terms of the ODL (Oracle Diagnostics Logging) Log Levels below

or as any of the Java Log Levels below

You can control the Log Level type (ODL or Java) through the drop down on the top right just above the Declares Handles column.

The Declares Handles column associates one or more log handlers to the specific logger. To illustrate, select a logger that has an associated log handler - an icon in the Declares Handles column - and expand the Handler Declarations section to display the associated log handlers.

The definition of the loggers in the Overview tab is hierarchical and is derived from top-down. For example: a logger that is specified at the oracle package level, applies to all other loggers below in the same hierarchy (oracle.*) unless it is overwritten.

All of this information and more is accessible in the Structure window. Let’s expand the logging_information node and then the log_handler node and let’s take a closer look at two of those log handlers:

 console-handler

This handler will log diagnostics to the console. Observe that the level attribute is set to ALL. This will allow the hander to log diagnostic messages for all log levels.

odl-handler
This handler will log ODL diagnostics to a log file. Expand the odl-handler log_handler node and observe the path property. It points to the location of the log file where the diagnostic logs will be saved. It is set to ${domain.home}/servers/${weblogic.Name}/logs/${weblogic.Name}-diagnostic.log, which is the C:\Users\username\AppData\Roaming\JDeveloper\system11.1.1.2.*.*.*\DefaultDomain\servers\DefaultServer\logs\ DefaultServer-diagnostic.log file in Windows 7.

OK. Let's generate some diagnostics now. Select the oracle.jbo logger in the Loggers tree and set its Level to FINEST – you may need to switch the log type to Java Log Types. This will override the default setting of the Root Logger in order to log all diagnostics generated by the oracle.jbo classes. There is no need to declare a specific handler, the one(s) defined for the Root Logger will be used as long as we ensure that the Use Parent Handlers checkbox remains selected. Make sure that you save the logging.xml file.

Before running your application open the ViewController Project Properties dialog, select the Run/Debug/Profile page and Edit… the Run Configuration. In the Edit Default Configuration dialog Launch Settings enter -Djbo.debugoutput=adflogger -Djbo.adflogger.level=FINEST in the Java Options.

Save the Project Properties and run your application. Observe the oracle.jbo diagnostic logs generated in the Log window. The same log entries are written in the C:\Users\username\AppData\Roaming\JDeveloper\system11.1.1.2.*.*.*\DefaultDomain\servers\DefaultServer\logs\ DefaultServer-diagnostic.log file as well.

Conclusion

ADF Diagnostics Logging is a powerful feature in JDeveloper. Through simple configuration, it allows you to fine tune the log generation of your application and much more.

Until the next time, keep on JDeveloping!

Code

http://jdeveloperfaq.googlecode.com/files/JDeveloperFAQNo6.rar

FAQ #5 - How to remote profile an ADF application deployed on standalone WebLogic using JDeveloper 11g R1

Introduction

Profiling is a valuable tool in the JDeveloper toolbox that can help us in the diagnosis of performance issues by identifying code that consumes more time, code that is called more often (CPU profiling) and how memory is used by the deployed application (memory profiling).

Main Theme

To demonstrate this FAQ, let's create a sample Fusion Web Application (Web) based on the HR schema. Let's create an Employee entity from the EMPLOYEES table and an Employees view based on the Employee entity. Finally, let's bundle the Employees view in the HrAppModule application module.

For the ViewController let’s create a View Activity called Employees directly in the unbounded adfc-config task flow and an Employees.jspx JSF page for the Employees View Activity. Finally, let’s drag the Employees view from the HrAppModuleDataControl in the Data Controls and drop it onto the Employees.jspx JSF page as an ADF Form.

Configure the application security and deploy onto the standalone WebLogic server as explained in FAQ #3 - How to deploy an ADF application on a standalone WebLogic server directly from JDeveloper.

If you have any issues related to security or connecting to the database when running the deployed application, take a look at the references section at the bottom for a couple of pointers.

Once the application is deployed, let’s verify that all is well by accessing the application URL in your browser. For the sample application attached, enter the URL http://localhost:7001/JDeveloperFAQNo5/faces/Employees. You should see the log in screen below.
   

 
Log in using jdeveloper/jdeveloper1. The Employees page below will be displayed.
 

 
OK, let’s do some profiling now!

To enable remote profiling, bring up the Project Properties dialog and select Run/Debug/Profile. Select the Default run configuration from the list of Run Configurations and click Edit….

In the Profiler page under Tool Settings enter the name of the package in our code based on which the profiler results will be filtered. For the sake of our sample application enter com.jdeveloper.faq.*. This will enable the profiling of all the java classes that we generated in the ADF BC.

Click OK a couple of times to exit from the Project Settings dialog and then save the project settings.

From the Run menu select Attach to | CPU Profilee.

In the Attach to CPU Profilee dialog select Attach to Local Process, select the weblogic.Server process and click OK.

Once attached, the Profiling ViewController tab will be displayed. Click on the Begin Use Case to begin a new profiling use case. That is, the icon on the top left with the green run triangle.

In order to generate profiling metrics, play around with the sample application deployed on WebLogic. As you can see CPU statistics are generated. The Hotspots tab displays the methods in the code where most CPU is spent in terms of percentage of CPU time. The Call Stacks tab displays the metrics in a different view.

There are all sorts of other goodies you can do while profiling. For example, saving a use case and then comparing it with the new one that you run after you make certain code changes could be useful to verify the changes in performance.

Conclusion

Profiling an application is another tool that could be of use when looking for bottlenecks and performance improvements in your application. It’s easy to setup and use. Give it a try!

Until the next time, keep on JDeveloping!

References

http://andrejusb.blogspot.com/2009/12/solving-error-403-forbidden-in-adf.html
http://radalcove.com/blog/?p=34 [at the bottom of the page]

Code

http://jdeveloperfaq.googlecode.com/files/JDeveloperFAQNo5.rar

FAQ #4 – How to remote debug an ADF application deployed on WebLogic using JDeveloper 11g R1

Introduction

In the project that I am currently involved, the main ADF enterprise application is split into smaller logical units each represented by a separate JDeveloper application workspace. Each application can be debugged separately in JDeveloper using the integrated WebLogic application server. If we need however to debug the whole ADF application as deployed on the application server, the only way we could do so is through remote debugging.

Main Theme

The basic steps involved in remote debugging an ADF application deployed in WebLogic are summarized below:

1. Installation and configuration of the WebLogic application server
2. Configuration of WebLogic to support remote debugging
3. Configuration of project in JDeveloper
4. Actual debugging of the application

Of course steps 1 through 3 are done only once. Then we can remote debug each time we like. Below we will expand on each of these steps.

1. Installation and configuration of the WebLogic application server
Please refer to FAQ #1 – How to configue the standalone WebLogic server for deploying ADF applications from JDeveloper 11g R1 (11.1.1.2.0) for information about how to install and configure WebLogic.

2. Configuration of WebLogic to support remote debugging

In order to allow for remote debugging, there are a couple of configuration changes that need to be done to the WebLogic domain. First we need to edit the domain startup script startWebLogic.cmd and specify JVM options for starting the server in order to support remote debugging of ADF applications. The domain startup script can be located in the %MIDDLEWARE_HOME%\user_projects\domains\<domain_name>\bin directory, where %MIDDLEWARE_HOME% is the installation directory of WebLogic (and usually of JDeveloper) and <domain_name> is the name of the domain created previously.

Add the following line before the set JAVA_OPTIONS= line:

set REMOTE_DEBUG_JAVA_OPTIONS=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=n

Change the set JAVA_OPTIONS= line to read like the one below:

set JAVA_OPTIONS=%SAVE_JAVA_OPTIONS% %ADF_JAVA_OPTIONS% %REMOTE_DEBUG_JAVA_OPTIONS%

Note that we added %ADF_JAVA_OPTIONS% in FAQ #1 – How to configue the standalone WebLogic server for deploying ADF applications from JDeveloper 11g R1 (11.1.1.2.0).

Finally we need to enable HTTP tunneling on the server. This is done after we first start WebLogic. To start WebLogic simply run the startWebLogic.cmd script. I have created a shortcut on the desktop to make it easily accessible.

Execute the startWebLogic.cmd script to start WebLogic and log onto the Admin Server Console. You can easily log onto the admin console by selecting the Admin Server Console from the Start Menu bar (Windows OS) - look under the Oracle Fusion Middleware 11.1.1.2.0 > User Projects > domain2 folder - or specifying http://localhost:7001/console in your browser.

Enter the username and password of the WebLogic administrator. You had specified the administrator credentials during the creation of the domain earlier. The default credentials are weblogic/weblogic1.

In the Home Page select Servers under the Environment section.

In the Summary of Servers click on the name of the server (AdminServer in this case).

In the Settings for AdminServer page select the Protocols tab and click on Enable Tunneling.

OK, we are almost there! A few more configuration changes in the JDeveloper project to be remotely debugged and we should be up and running with remote debugging in a sec.


3. Configuration of project in JDeveloper

First let’s create a run configuration specifically for remote debugging. Double-click on the ViewController project in your ADF application to bring up the Project Properties and select the Run/Debug/Profile page. Click New… to create a new run configuration. In the Create Run Configuration dialog enter Remote Debug for the name of the run configuration. Leave the Copy Settings From selection to Default and click OK to create the new run configuration.

Once the Remote Debug run configuration is created, select it in the Run Configurations and click Edit… to bring up the Edit Run Configuration dialog. In the Launch Settings page click on the Remote Debugging checkbox to enable remote debugging for this run configuration.

Finally select the Remote page and verify that the Protocol is set to Attach to JPDA and the port matches the port specified earlier when configuring WebLogic for remote debugging (defaults to 4000).

4. Actual debugging of the application

Now we are ready to remote debug our ADF application. Well, almost! First we need to create a connection to the WebLogic server, create deployment descriptors for the project and the application and deploy our ADF application to server. To deploy directly from JDeveloper refer to FAQ #3 - How to deploy an ADF application on a standalone WebLogic server directly from JDeveloper.

Once the application is deployed to the WebLogic server we can get down with the actual remote debugging task. To do so, right-click on the ViewController project and select Start Remote Debugger from the context menu.

Verify the attachment details shown in the Attach to JPDA Debugee and click OK to attach to the remote debugger.

That’s it, you are remote debugging! Bring up your application on your Web browser and test it. Debug as usual, setting break points, watching variables, examining the calling stack and so on.

Conclusion

Remote debugging comes handy in situations where enterprise applications are split-up across multiple JDeveloper application workspaces. Also it comes handy if you want to keep different reference versions of the application deployed on the server and you want to debug an older or different version. I have also noticed substantial performance improvement in JDeveloper during the remote debugging session.

Until the next time, keep on JDeveloping!

References

http://www.oracle.com/technology/products/jdev/howtos/weblogic/remotedebugwls.html

FAQ #3 - How to deploy an ADF application on a standalone WebLogic server directly from JDeveloper

Introduction
Once we have installed and configured the standalone WebLogic server it becomes easy to deploy our ADF applications directly through JDeveloper.


Main Theme

Deployment of ADF applications into the standalone WebLogic server could be done in a number of ways. In this FAQ we will explore how to deploy directly from JDeveloper.

To demonstrate deployment directly from JDeveloper, let's create a sample Fusion Web Application (Web) based on the HR schema. Let's create an Employee entity from the EMPLOYEES table and an Employees view based on the Employee entity. Finally, let's bundle the Employees view in the HrAppModule application module.

For the ViewController let’s create a View Activity called Employees directly in the unbounded adfc-config task flow and an Employees.jspx JSF page for the Employees View Activity. Finally, let’s drag the Employees view from the HrAppModuleDataControl in the Data Controls and drop it onto the Employees.jspx JSF page as an ADF Form.

In order to deploy our application, we first need to create an Application Server Connection to the standalone WebLogic server. First let’s start WebLogic if not yet started. Then, in the Resource Palette (View

Resource Palette) let’s create a new Application Server connection.
 

In the Create Application Server Connection wizard Name and Type page specify the Connection Name, ensure that the Connection Type is set to WebLogic 10.3 and click Next.
 

In the Authentication page specify the WebLogic server Username and Password.
 

In the Configuration page specify the WebLogic Hostname – localhost for our development machine, the server Port – defaults to 7001 - and the Weblogic Domain name that we will be deploying on.
 

 
In the Test page click on the Test Connection button to test the connection and verify that all tests are successful.
 

 
Click Finish to save the connection which will appear in the IDE Connections in the Resource Palette.
 
Now we are ready to deploy our application. From the Application Menu – at the top left next to the application selection – select Deploy… and then the name of the deployment.
 

The first time around a Deployment wizard will be displayed. In the Deployment Action page select Deploy to Application Server and click Next.

In the Select Server page select the application server connection we created earlier from the listed Application Servers. Uncheck the Deploy to all server instances in the domain option if you want to deploy on a specific server instance. Leave the Deploy as a standalone Application option selected and press Next.

If you unchecked the Deploy to all server instances in the domain option in the previous page, a Server Instances page will be displayed. Select the Server instance that you will be deploying – ensure that the status of the server instance is RUNNING – and click Next.

In the Summary page verify the Deployment Summary details and click Finish to start the deployment process. The status of the deployment process is displayed in the Deployment – Log window. The deployment process first creates the Web Application Module (war), then the Enterprise Application Module (ear) and finally deploys the application onto the server instance(s). If all goes well the message Application Deployed Successfully is shown in the log window.

That’s it. Our application has been deployed into the standalone WebLogic server. To verify that this is the case, log in into the WebLogic administrator console – http://localhost:7001/console - and click Deployments in the Domain Structure tree. In the Summary of Deployments you should see the application we’ve just deployed.

We can access our deployed application by entering the application URL – http://127.0.0.1:7001/JDeveloperFAQNo3/faces/Employees - on the browser. At this point the application won't initialize and the Employees page won’t load until we enable security in our application. We will see how to do that some other time.

Conclusion

Once we install and configure the standalone WebLogic server in our development machine, deploying an ADF application directly onto it directly from JDeveloper is a piece of cake. Just make a connection to the server in JDeveloper and deploy!

Until the next time, keep on JDeveloping!

Code

http://jdeveloperfaq.googlecode.com/files/JDeveloperFAQNo3.rar