Tuesday, June 7, 2011

FAQ #35 - How to set default values for View object row attributes


In this post we will see how to set default values to View object attributes. There are a number of places where you can do this:

  • In the overridden View object row create() method
  • Declaratively using a Groovy expression
  • In the attribute getter method

To demonstrate each case, consider the use case of setting the employee’s hire date to the current date for a newly created View object row.

Main Theme

Setting default attribute values in the overriden ViewImpl create()

To set the default value for a View object attribute in the overridden create() method, follow these steps:

  • Create a View Row custom Java implementation class for the Employees View object.
  • Open the EmployeesRowImpl.java custom View Row Java implementation class and override the create() method using the Override Methods… button – the green left arrow on the editor toolbar.
  • To set the default employee’s hire date to today’s date, add the following code to create() immediately after the call to super.create():
              // set the default hire date to today

Setting default attribute values with a Groovy expression

To set the attribute default value using a Groovy expression, follow these steps:
  • Open the Employees View object definition and go to the Attributes page.
  • Select the attribute that you want to initialize – HireDate in this case, and click on the Edit selected attribute(s) button (the pen icon).
  • On the Edit Attribute dialog select the View Attribute node.
  • Select Expression for the Value Type radio button in the Attribute section.
  • Enter the following Groovy expression in the Value field: adf.currentDate

Returning a default value from the attribute getter

Another way to set a default value for a View object attribute is in the attribute getter method. Follow these steps to set the default employee hire date:

  • Locate the View object attribute getter in the View object custom row implementation class. In this example is the getHireDate() method in EmployeesRowImpl.java.
  • Replace the existing code in getHireDate() with the following:

          // get the HireDate attribute value
          Date hireDate = (Date)getAttributeInternal(HIREDATE);
          // check for null and return today's date if needed
          return (hireDate == null) ? (Date)Date.getCurrentDate() : hireDate;

Note that using this technique we don’t actually set the attribute value; rather we return a default value, which can be subsequently applied to the attribute. Also notice that this is done only if the attribute does not already have a value (the check for null).

Actually setting an attribute value in a getter is not a recommended practice.

Attribute dependency

A common use case related to this topic is setting an attribute’s value based on the value of another related attribute. Consider for instance the use case where the employee’s commission should be set to a certain default value if the employee is part of the Sales department. Also consider the case where the employee’s commission should be cleared if the employee is not part of the Sales department. In addition to accomplishing this task with Groovy as stated earlier, it can also be implemented in the employee’s DepartmentId setter, i.e. in the setDepartmentId() method as it is shown below:

    public void setDepartmentId(Number value) {
        // set the department identifier
        setAttributeInternal(DEPARTMENTID, value);
        // set employee's commission based on employee's department
        try {
            // check for Sales department
            if (value != null && SALES_DEPARTMENT_ID == value.intValue()) {
                // if the commission has not been set yet
                if (this.getCommissionPct() == null) {
                    // set commission to default
                    this.setCommissionPct(new Number(DEFAULT_COMMISSION));
            } else {
                // clear commission for non Sales department
        } catch (SQLException e) {
            // log the exception


As you can see, there are a number of different ways for initializing your View object row attributes. Which one you choose depends on the specific use case at hand. It is common on large projects that a combination of all (and more) is used. Setting a standard approach could be appropriate in this case.

Until the next time, keep on JDeveloping!

Monday, May 9, 2011

FAQ #34 - How to utilize WebLogic Work Managers for long-running ADF processes, Pt. 1


The WebLogic Work Manager functionality along with its supporting Java API - CommonJ, can greatly improve performance for those long running processes in your ADF applications, especially for those notorious ones - you know, the one that cause "stuck" threads? This is true because these long running processes can now run asynchronously on a specific Work Manager that you define, one that is configured to ignore "stuck" threads. Let's take a look.

Main Theme

Adding and configuring a Work Manager in WebLogic

You define a Work Manager in WebLogic by selecting Work Managers under the Environment node in the Domain Structure window and clicking New on the Summary of Work Managers page on the right on the Global Work Managers, Request Classes and Constraints table.

On the Select Work Manager Definition type page select Work Manager and click Next.

On the Work Manager Properties page enter the name of the Work Manager and press Next.

On the Select deployment targets page select the Work Manager targets and click Finish to complete the creation of the Work Manager.

The Work Manager will now appear in the Summary of Work Managers table. Click on it to bring up the Configuration page. In it select Ignore Stuck Threads and click Save. This will configure the Work Manager to ignore "stuck" threads for long running processes. We won't be changing the other configuration settings for this Work Manager.

Configuring the Work Manager for your application

To configure the Work Manager for your application, edit the web.xml file and enter the following resource reference:


This is necessary so that you will be able to access the Work Manager programmatically as it shown below.

Programmatically submitting works to the Work Manager

Here is an example of a long running process in an ADF application and a good candidate to produce a "stuck" thread:

    public void selectAll() {
          RowSetIterator iterator = getMyViewObject().createRowSetIterator(null);

          // loop over 1,000,000 records...
          while (iterator.hasNext()) {
              MyViewObject myViewObject = (MyViewObject)iterator.next();

This is a method in the Application Module that loops over a large number of records - possibly millions - in order to set some boolean flag. Below we will re-write the code using the Work Manager Java API CommonJ.

First you will need to add support for the CommonJ API in your ADF application. The CommonJ API is located in the weblogic.jar library, so use the Libraries and Classpath option in the Project Properties and add it. The library can be found in the wlserver_10.3/server/lib directory in your WebLogic installation directory.

Now modify the method above to the following:

        public void selectAll() {
        try {
          //get Work Manager from local JNDI
          InitialContext ctx = new InitialContext();
          WorkManager workManager = (WorkManager)ctx.lookup("java:comp/env/wm/TestWorkManager");
          //create instance of Work and WorkListener implementations
          Work work = new SelectAllWorkImpl(getMyViewObject().createRowSetIterator(null));
          WorkListener workListener=new SelectAllWorkListener();
          //create work item for execution
          WorkItem workItem = workManager.schedule(work, workListener);
          //create list of WorkItems that we want to execute
          List workItemList=new ArrayList();
          //run the work items in parallel; don't wait
          workManager.waitForAll(workItemList, WorkManager.IMMEDIATE);
          //check results; use only if you are blocking
          //SelectAllWorkImpl workImpl= (SelectAllWorkImpl)workItem.getResult();
        } catch (NamingException e) {
        } catch (WorkException e) {
        } catch (InterruptedException e) {


In this first installment of discovering Work Managers in WebLogic, we've seen how to create one and how to configure it and use it in your application. We will wrap up this topic on the next installment. There we will explain the code above and provide the implementations of Work and WorkListener interfaces. This is indeed a promising feature that should help in certain cases where long running processes can cause "stuck" threads.

Until the next time, keep on JDeveloping!

Tuesday, March 22, 2011

FAQ #33 - How to configure ADF diagnostics logging in WLS, Pt. 3


In this third installment of posts related to the configuration of ADF diagnostics logging we will focus on the following topics: 1) how logs could be added programmatically to the diagnostics log, 2) how new Loggers could be added and configured to the diagnostics logging configuration and 3) how to dynamically configure the WebLogic diagnostics logging. This includes changing the logging levels for the configured loggers at run-time without the need to restart the server.

Main Theme

For some background information regarding diagnostics logging as it relates to ADF, JDeveloper and WebLogic refer to these earlier posts: FAQ #6 - How to fine tune ADF diagnostics logging in JDeveloper 11g R1  , FAQ #7 - How to configure ADF diagnostics logging in standalone WLS using JDeveloper 11g R1 and FAQ #8 - How to perform log analysis using the Diagnostic Log Analyzer in JDeveloper 11g . The main advantages of using Oracle Diagnostics Logging (ODL) when compared to other logging frameworks is its tight integration with WebLogic and JDeveloper. In WebLogic, the logs produced conform to and integrate with the diagnostics logging facility. Diagnostic logs include in addition to the message logged additional information such as the session and user that produced the log entry at run-time. This is essential when analyzing the logs. In JDeveloper the log configuration and analysis is integrated via the Oracle Diagnostics Logging Configuration and Oracle Diagnostics Log Analyzer respectively. Both are discussed in detail in the above referenced posts.

Programmatic Usage

Diagnostic logs can be generated programmatically from within your code by using the ADFLogger class. You simply instantiate an ADFLogger via the static createADFLogger() method and use its log() method. log() accepts a java.util.logging.Level parameter indicating the log level of the message that you are logging and it can be any of the ADFLogger.INTERNAL_ERROR, ADFLogger.ERROR, ADFLogger.WARNING, ADFLogger.NOTIFICATION and ADFLogger.TRACE. You can also use the severe(), warning(), info(), config(), fine(), finer() and finest() methods to do your logging. Here is an example:

// create the ADFLogger
private ADFLogger logger = ADFLogger.createADFLogger("package.class");
// log a trace
logger.log(ADFLogger.TRACE, "A trace log");

Configuration of Custom Loggers in JDeveloper

In the ADFLogger example above, "package.class" is a custom logger which is associated with the ADFLogger. You will need to configure this custom logger in the diagnostics logging configuration file logging.xml. Ensure that you load the appropriate logging.xml file for the WebLogic server you are configuring. The file can be found in the domain config\fmwconfig\servers directory for each server. So, open the appropriate logging.xml configuration file in JDeveloper and create a custom logger called "package.class" by clicking on the Add Logger icon as it shown below.

In the Add Persistent Logger dialog that is presented add the logger class specified above in the ADFLogger (i.e. package.class), set its logging level and click OK.

The custom logger will appear in the list of Loggers as it shown below. With its logging level set appropriately, your trace log in the earlier example will show in the diagnostics log.

Dynamic Configuration of Logging in WebLogic

Diagnostics logging can be configured dynamically in WebLogic via the wlst tool. Ensure that you run the wlst script located in the oracle common directory  - %MIDDLEWARE_HOME%\oracle_common\common\bin for a JDeveloper installation - and not the one under the WebLogic server home - %MIDDLEWARE_HOME%\wlserver_10.3\common\bin for the stand-alone WebLogic installed along with JDeveloper. The former provides custom commands for configuring diagnostics logging. First you will need to connect to the admin server via the connect() command as in connect('weblogic','weblogic1','t3://address:7001'). To change the logging level for the custom logger class above, use the setLogLevel() command as in setLogLevel(target="ManagedServer1", logger="package.class", level="ERROR"). Specify the target WebLogic server with the target= argument (ManagedServer1 in this example), the logger class with the logger= argument and the new logging level with the level= argument. It can be either a Java level or an ODL level. Some valid Java levels are: SEVERE, WARNING, INFO, CONFIG, FINE, FINER, or FINEST. Valid ODL levels include a message type followed by a colon and a message level. The valid ODL message types are: INCIDENT_ERROR, ERROR, WARNING, NOTIFICATION, TRACE, and UNKNOWN. The message level is represented by an integer value that qualifies the message type. Possible values are from 1 (highest severity) through 32 (lowest severity). Additional commands for dynamic configuration of the diagnostics log will allow you to configure the Log Handler for each logger class, display the currently configured loggers and so on. For more details, check out the documentation references sited below.


If you are considering a logging framework for an application to be deployed on WebLogic, I suggest that you take a closer look at the Oracle Diagnostics Logging facility. Its tight integration with JDeveloper (logging configuration and log analysis) and WebLogic (diagnostics log format, dynamic configuration) makes it a comparable choice.

Until the next time, keep on JDeveloping!


Logging Custom WLST Commands
Using Custom WLST Commands

Sunday, March 13, 2011

FAQ #32 - How to get started with JRockit Mission Control, Pt. 1


JRockit Mission Control is a suite of tools that can be used to monitor, profile and manage the JRockit Java virtual machine. Among other, managing the JRockit Virtual Machine includes performing garbage collection on demand and eliminating memory leaks. JRockit is the virtual machine used in a production system by the WebLogic application server.

Main Theme

Installation of JRockit Mission Control

JRockit Mission Control must be installed on a client machine through which a target JRockit virtual machine running on a server machine can be monitored, profiled and managed. To download JRockit Mission Control, go to the JRockit Family Download page.

Accept the license agreement, select the appropriate version for your client operating system and proceed with the download. Once downloaded, start the installation by executing the file downloaded. Follow the installation wizard choosing in most cases the default options presented by the installer.

During the installation you will be given the option to install the JRockit JRE in the client machine. Select Yes (Install Public JRE) and click Next to proceed.

The installer will proceed with the installation of both the JRockit JRE and the JRockit Mission Control. Verify that the installation was successful and click Done.

Once installed, you can start the JRockit Mission Control by running the jrmc program in the target installation directory. When installed on a Microsoft Windows operating system a shortcut called Oracle JRockit Mission Control 4.0.1 is created under the Oracle JRockit JDK R28.1 for Java SE 6 with JRMC 4.0.1 (32-bit) group - for the version installed.

Before proceeding with Mission Control, you will have to configure the target JRockit Java virtual machine to allow its management via the Mission Control suite.

Configuration of target JRockit Java Virtual Machine

For the sake of this example, we will configure a WebLogic SOA deployment consisting of one administration server and two managed servers - one for SOA and another for BAM. Similar configuration steps can be taken to configure your own setup. Start by ensuring that your WebLogic is configured to run on the JRockit Java virtual machine. This should be the case in all production environments. To ensure that we are indeed using JRockit, we will manually set the JAVA_VENTOR parameter to Oracle in the setDomainEnv script.

We will also add a parameter called ENABLE_MNGMNT_CONSOLE in setDomainEnv to control whether JRockit is started to allow its management.

Thats all with the setDomainEnv script. We will proceed by adding a few lines in the startWebLogic script. Here we will check to see whether the management console is enabled and if it is we will check if the management console startup options are set. If there are none specified, we will specify some defaults. We will see below when configuring the managed servers that the management console start up options can be set in the startManagedWebLogic script. The lines that we will add to the startWebLogic script are:

As you can see in the above picture, we are starting the JRockit virtual machine with the -Xmanagement switch specifying no secure sockets, no authentication and 7091 as the default connection port. Each WebLogic server must be configured to allow Mission Control connections on a separate port.

We will conclude the configuration changes by adding the following lines to the startManagedWebLogic script:

What we have done here is configure a different JRockit management port for each managed server. In this case we need to make sure that the actual names of the managed servers are correct, so this needs to be adapted for your setup.

Now we can start the SOA domain. For each server, observe that the management options are set correctly.

Mission Control Connection Setup

Now that we have the target JRockit virtual machines configured to allow Mission Control management connections - remember that each WebLogic server runs on its own virtual machine, we can proceed by creating the connections to each virtual machine from within the Mission Control suite. To create a new connection, right-click on the Connectors node and select New Connection.

In the New Connection dialog specify the WebLogic server host name or IP address, the management connection port and the connection name. Click on the Test connection button to test the connection.

We will create a separate connection for each WebLogic administration and managed server configured for the SOA domain above. After creating all the connections the Mission Control suite should look like this:

To start a monitor session for each configured virtual machine, right-click on the appropriate connection  and select Start Console.

This will open a monitor console as it is shown below.

Additional monitor consoles can be opened by right-clicking on another connection and selecting Start Console. Each monitor session will be shown in a separate tab in Mission Control.


This concludes this first part of getting started with the JRockit Mission Control. In the next part we will look at some of the features of the Mission Control.

Until the next time, keep on JDeveloping!



Wednesday, February 9, 2011

FAQ #31 - How to create your own in-house Update Center in JDeveloper


If you ever used the Check for Updates... feature in JDeveloper, I am sure you've seen the list of available Update Centers from which you can download your JDeveloper extensions. In this post we will go through the process of adding your own Update Center to supply your own extensions in a corporate environment.

Main Theme

You can access the Check for Updates... feature in JDeveloper via the Help | Check for Updates... menu. Once you do so, a list of the available Update Centers is presented as shown in the picture below.

It is easy to add your own Update Center by clicking on the Add... button and supplying the necessary information, i.e. the name of the Update Center and its location.

The Update Center location is the http address of the Update Center descriptor as in in the above example. The Update Center descriptor is an XML file describing the Update Center and the extensions that makes available. Below is an example descriptor:

The updates tag encloses all available extension updates that are made available by the Update Center. Each extension is listed within the update tag. The information provided in the nameversionauthorauthor-url and description tags are used by JDeveloper to present the necessary information about the specific extension. The bundle-url tag points to the location from where the extension can be downloaded. It does not need to reside in the update location necessarily.

After adding the update center, the Check for Updates... page will reflect the Update Center added as it is shown below:

Selecting the newly added Update Center and clicking Next will present a list of the extensions that are made available by the Update Center.


Adding your own JDeveloper Update Center to supply your own extensions is a pretty straightforward business. Just add it in the Check for Updates... and provide the appropriate Update Center descriptor to describe the JDeveloper extensions that are made available by the Update Center. Of course you've got to have your Update Center web server up and running and your extensions on-line to start serving the extension download requests ;)

Until the next time, keep on JDeveloping!

Related Posts Plugin for WordPress, Blogger...