by Oracle ACE Director Wilfred van der Deijl and Oracle ACE Richard Olrichs
JDeveloper audit rules provide developers and projects with the ability to assess code quality for best practices, code violations, typical errors or warning scenarios. The ability of teams to create custom JDeveloper audit rules lets developers identify code quality issues—beyond what Oracle has provided—specific to their environment.
Contents
- Introduction
- Setting up the environment
2.1 Prerequisites
2.2 Extension SDK
- Create a test application
- Create the Extension Application
4.1 Extension.xml
4.2 The Analyzer class
4.3 Creating the Custom Rule
4.4 Using the Resource Bundle
- Creating a Custom Fix
- Creating a Java rule
- Distribute the Extension
7.1 Creating a bundle.xml
7.2 Creating a deployment profile
7.3 Cleaning JDevs extensions and cache
7.4 Create an Update Center
- Conclusion
Introduction
In a software development process, quality assurance (QA) is usually postponed until the very end, when there is little or no time left. After functional testing, bug fixing and—optimally—performance testing your application, there might be some time left for writing documentation. And with that, the project ends.
In our experience, one of the main reasons for this (bad) habit is that QA tools are not usually embedded into the development process and, if they are, they are time consuming and cumbersome, with few perceived benefits to the developer.
JDeveloper offers a solution. JDeveloper extensions can apply code quality checks and rules to the code you write when you're writing it, rather than as a post-review exercise. These custom extensions extend JDeveloper's built-in Audit Framework in the community project ADF EMG Audit Rules, the ADF Code Guidelines from Oracle are coded into audit rules.
You can also add additional rules to JDeveloper to suit the QA needs of your enterprise. In this document we will show you how to start coding your own audit rules. We will begin with building a small Application Development Framework (ADF) to test our audit rule, and will move on to creating the Audit Rule. This rule will check the PageDef of the ADF application and check the value of the CacheResults property from the iterator. We use an ADF example, but the same approach applies to any application build within JDeveloper (e.g., a service-oriented architecture (SOA) composite or plain Java EE). The ADF application you build will be very small, and we'll provide a step-by-step guide; you should be able to follow this tutorial without any knowledge of ADF.
This tutorial is based on JDeveloper 12c. We suggest you get the latest and greatest version of JDeveloper (12.1.3 at the writing of this tutorial). However, if you are working with an earlier version of JDeveloper 12c, like 12.1.2, you should be able to follow this tutorial as well.
You can get JDeveloper 12.1.3 here and you can find the relative documentation from Oracle on how to build an JDeveloper extension here.
2. Setting up the Environment
To build JDeveloper extensions to implement audit rules, you will use Oracle JDeveloper itself. By default, JDeveloper does not include the extension SDK, so the following sections describe how to configure JDeveloper to build your own audit rule extensions.
2.1 Prerequisites
We assume you have JDeveloper version 12.1.2 or 12.1.3 installed. If not, you can get it here.
2.2 Extension SDK
To get the extension SDK for JDeveloper, go to Help > Check for Updates:
Leave the default checkboxes, as shown below, and click Next:
Choose Extension SDK and click Next:
You'll see the extension being downloaded and installed:
After this, you'll be asked to confirm the installation by clicking Finish:
Click Yes to restart JDeveloper.
Wait while JDeveloper is restarted:
Next, choose whether to add the examples or not. We do not need them for this tutorial, and you can always get them later if you want to.
3. Create a Test Application
Before writing a rule for JDeveloper to enforce, it's useful to have an actual test application that you can run the rule against. We'll start by creating part of this testing application called “BadPractise.”
Click the New button in JDeveloper:
Click Applications and choose ADF Fusion Web Application:
Fill in the Name, Directory and default Application Package Prefix for the application, then click Finish (we'll leave all the other options to default):
For the purposes of testing, we do not need an application that shows real data from a database. The Placeholder Data Control (see figure below) provides a convenient mechanism for hard coding sample data into our application for testing purposes.
Right click on ViewController and select New and From Gallery.
In New Gallery select Business Tier > Data Controls > Placeholder Data Control:
Accept the defaults and click OK:
Open the created PlaceHolder.xml:
Select the Placeholder option in the Data Types section, and add a data type using the green + symbol:
Accept the default and click OK:
Open the Attribute tab, and add an attribute by clicking the green + symbol:
Repeat this process to create three attributes: Name, Address, Gender.
Save all.
The Data Control is now complete and can be used in the page. Check this by opening the Data Controls panel in your Application Navigator and refreshing the data control.
Within this tab you will see the created Placeholder Data Control and the PlaceholderDataType with the created attributes within.
You can now close Placeholder.xml and PlaceholderDataType.xml.
Open adfc-config.xml in the WEB-INF folder:
From the Components palette, drag and drop a View activity to the adfc-config.xml:
Enter a name (e.g., "Page"):
Double click this created activity to open the Create JSF Page wizard:
Accept the defaults and click OK.
On the newly created page, drag and drop PlaceholderDataType:
From the Create menu, select Table/List View and then ADF Table:
In the Create Table wizard, accept the defaults and click OK:
Your resulting page will look like this:
Right click within the page and select Go to Page Definition:
The resulting PageDefinition will appear as in the figure below:
Within the Executables section, select the PlaceholderDataTypeIterator:
In the Properties panel, click the Advanced tab and select false for the CacheResults property, as in the figure below:
For now, this is enough to test the first rule we're going to create.
Before closing all the tabs, take a look at the source file from the PageDef you just created. You will see the following XML code about an iterator with the CacheResults property set to false:
Close the tabs that are still open, if you like.
>>Continue to Part 2>>
About the Authors
Oracle ACE Director Wilfred van der Deijl has been working with Oracle's development tools and database ever since getting his degree in Computer Science in 1995. An active member of the Oracle community, Wilfred is a blogger, author, Oracle customer advisory board member, and a frequent presenter at international conferences, including ODTUG and Oracle OpenWorld.
Oracle ACE Richard Olrichs is an Oracle Developer at MN, a technology company based in the Netherlands. Richard Olrichs has an extensive in Oracle Fusion Middleware with deep specialization in the Oracle Application Development Framework. Richard initiated an open source project creating an ADF EMG Audit Rules extension for both JDeveloper 11g and JDeveloper12c, and was also one of the initiators of ADF EMG XML DataControl, an open source project for both JDeveloper ADF 11g and JDeveloper ADF 12c. Richard is has spoken at Tech 13, Tech 14, and Oracle Open World 2014.