Pages

ADF EMG Audit Rules 1.0 Released

Today at the UKOUG I showed a new plug-in for JDeveloper 12c together with Wilfred, the ADF EMG Audit Rules. You can find it through JDevelopers Check for Updates in the Help menu. This plug-in is a starting point for creating rules out of the code guidelines document you can find on the ADF Architecture square.


In two previous blogs I showed you how to create audit rules and how to create a fix for your audit rule using the JDeveloper Extension Framework. If you want to get your hands dirty writing some of your own rules, there now is a good starting point for that.


The idea was created during a few sessions with Wilfred van der Deijl creating our presentation, Quality Assurance with the JDeveloper Auditing Framework, for the UKOUG. The goal is to try and create an extension project, to automate ADF coding standards and best practises. The current idea is to use the ADF Code Guidelines document as starting point to create custom rules.


As time is always a critical matter in situations like this, all help is welcome. Anyone who wants to contribute and help us writing code/rules/fixes/etc is welcome to do so. I think it would be a create feature for the whole ADF community if we can write an extension that checks the most common pitfalls already during development.

As we speak we’re still working on an SonarQube plug-in to automate this rules and make them visible in JDeveloper as well as SonarQube.


Resources:
- The ADF EMG Audit Rules project on java.net.
- The ADF EMG on google.
- A thread on ADF EMG about this subject.
- The ADF Architecture Square
- The ADF Code Guidelines v1.00

Uninstall your JDeveloper Extension

Since JDeveloper 12c it’s possible to uninstall extension from your JDeveloper, without deleting jar files and cache directories manually. However, the feature is a little bit hidden, it’s not in your preferences, but in the feature section. You get there through the Tools menu.


Here you can manage your features, check for updates and clear the cache if you want to.

Now if you go to the second tab, installed updates, you get an overview of the updates installed on your JDeveloper.

If you tick for example JUnit, JDeveloper is also smart enough to recognize the dependency. It warns you that you need to uninstall both the bundles.

Next you can click the uninstall button and restart JDeveloper.

That's all it takes to uninstall an extension in JDeveloper 12c.

Write a fix for your audit rule

In a previous blog I described how to build an audit rule in JDeveloper 12c, besides the audit rule, you can also write a fix for this rule. In this example, the fix isn’t anything fancy, but it gives you an idea on how to write more complex fixes. The rule we created in the previous blog was one to check if there was an iterator in a pagedefinition file that has the attribute cacheResults set to false. 
The fix for this rule will be to set the value back to true. 

First we open the Extension.xml, in the Extension.xml insert a transform definition inside the audit-hook:

 Inside the rule-definition, insert a transform-binding:

 In the popup enter the ID you choose for the transform-definition.
The result in the extension file should like something like this:

        
            
                
                    JSF
                
                
                    nl.olrichs.audits.IterCacheTransform
                
                
                
                    sample-category
                    true
                    warning
                    
                        transform-iter-cache
                                        
                
                
                     nl.olrichs.audits.IterCacheAnalyzer
                
            
        
    
In the resource bundle, create a property for the label to display, take the transform-definition id and add .label behind it. In this case:
Next we need to create the actual Java Transform class.
This class needs to extend the oracle.jdeveloper.audit.transform.Transform class. In this class we need to create a default constructor, in this case we’re fixing an XML document (the pageDef), so we want to call the super with a new XmlTransformAdapter.

/**
     * Default no-arg constructor.
     * Calls the super with new XmlTransformAdapter.
     */
    public IterCacheTransform() {
        super(new XmlTransformAdapter());
    }
    
    /**
     * Set the attribute value (cacheResults) to true.      
     */
    public void apply(XmlTransformContext xmlTransformContext, Attr attr) {
        attr.setValue("true");
    }    

As we've seen for the audit rule with the enter and exit methods, you can write a fix (apply) for different levels (for example: Document, Element, Attr) as well. In this case we only need an fix on the Attr, so we only create an apply on this level.

Don’t forget to deploy to the Target Platform before running your extension. The result is not only a warning in the pageDef, it is also a suggestion for a fix with the label we defined in the bundle.


When you click the fix, you will see the value toggle from false to true.


For more information about creating Audit Rules, please check out my index page on topics around this subject.

Book Review: ‘Developing Web Applications with Oracle ADF Essentials’

Packt asked me to review the book ‘Developing Web Applications with Oracle ADF Essentials’ by Sten Vesterli. The book isn’t exactly a bible, it’s 270 pages long and an easy read. Sten jumps onto the recently released ADF Essentials and takes you by the hand on how to write ADF Essentials applications.
In every chapter he first explains the technique and after that uses the described technique to build a DVD rental application. You can follow his steps and build this application for yourself as well.


About the author
Sten Vesterli is an Oracle ACE Director, recognized by Oracle as one of the top 40 independent experts on Oracle Middleware and SOA. He is a regular Oracle OpenWorld presenter and also frequently speaks at Oracle user group conferences. He has written more than 60 articles and conference papers on Oracle development as well as the book Oracle Web Applications 101.

About the book
The first chapter is not about ADF Essentials, but about everything to get your environment up and running. Different freeware is installed, a MySQL database, the Java Development Kit and a GlassFish application server as well as the JDeveloper IDE and ADF Essentials toolkit.

After that, he dives into ADF going through the different layers, starting with the Business Services layer. Here the basic functionality of ADF Business Component gets explained. In chapter 3 the ViewController layer and the Model layer get explained all with the use of examples and through declarative development, showing the powers of ADF.

In Chapter 4 ‘Adding Business Logic’, the focus is more on the power of Java than on declarative development. First is shown how you can extend the business components framework. After that how to create managed beans and how to access data through the binding layer is described.

From there the focus moves away from the ADF functionality and chapter 5 is dedicated to the project setup, application architecture, project team and development structure. The example application that is build throughout Chapter 2 through 4 gets restructured as an example of how the structure of an enterprise application could look like. The deployment profiles get set up and library management is arranged.

The next subject is debugging and logging. For logging this means subjects like how to set up your logging, how to create code templates and how to interpret the output in the logfile. For debugging this includes how to set up debugging and how to debug ADF libraries used in your application.

Chapter 7 is about Security, since security isn’t a part of the ADF Essentials toolkit, Sten gives a good alternative and explains how to set up Shiro from Apache with your ADF application. Not only authentication but also authorization based on a permission & role system is explained.

Last but not least, the final chapter: ‘Build & Deploy’. In this chapter it is explained how Ant can be used for scripting the creation of artifacts and how asadmin can be used for scripting (command-line) your deployment to GlassFish. If you want to use automated build tools, explained is how to use Ant to automate all the steps (including the asadmin step).

Critical notes
In his book a lot of times Sten uses simplified or easy examples, he then posts a note to the documentation or a blog post with more information about the subject. I think this is a very good and strong tactic. However, during chapter 4, multiple times get described how you can use bindings in your page to bind a UI component in a bean class. This is done in the standard way JDeveloper generates this code for you. In light of this event I would like to point out this is considered a bad practice. See this blog post from A-team member Steven Davelaar for more info on the best practice.

In chapter 5, Sten gives his view on how to organize a project/application setup in which he uses the following example:

I would like to point out that this is one way of setting up a project structure, but there are many more. If you are interested in hearing more about this the ADF Architecture Square has a youtube channel which include a few movies about this subject.

In the last chapter about building & deploying, it is described how you can use Ant in your master workspace, to look at all the different subsystems and build & retrieve their artifacts. While this works and is a valid method for smaller applications. I wouldn’t recommend this structure for large enterprise applications. There are a lot of different ways to set up library management with tools like ant & ivy or maven. If you’re new to this subject, I would advise you to read some more documentation and information on this subject first, before making a decision in the setup of your library management.

Conclusion
First of all, the book is a very good read. It explains clearly the core functionality of ADF & ADF Essentials. It explains in less than 300 pages how you can set up your whole environment with nothing but freeware. This book also fills one of the biggest caps in ADF Essentials, the lack of build in security.
If you’re new to ADF, or never even tried it out, this book is definitely a good starting point for you!!

Write your own Audit Rule Extension in JDeveloper 12C

JDeveloper comes with a nice audit framework, one of the great things about this framework is that you can write your own code to check for specific standards or fire specific rules you want to check. If you want to write extensions in 11g I recommend one off the two following posts:
For 11R1 check Arvinder Singh's blog.
For 11R2 check John ‘JB’ Brock's blog.
JDeveloper 12C is more like the 11R2 way, but still differs in some things. Especially the blog entry by John 'JB' Brock was very useful to me.

For more information about creating Audit Rules, please check out my index page on topics around this subject.

Now, before you start, don’t forget to get the Extension SDK in JDeveloper, this is very easy to download through Help -> Check for Updates -> Extension SDK. In this example I wrote a simple rule, that checks the pagedef file for iterators and wether the cacheResults property is set to false. If so, it throws a warning to point out that this setting might not be the way you want it.

Start a new Application and pick the Extension Application:

Give it a good name and except all the defaults in the other steps. By default JDeveloper creates a Res.properties file for you that is your resource bundle. Next to that it creates an extension.xml and a Manifest.mf.

The extensions.xml is much cleaner in 12C, the Manifest takes over some tasks from this extension file. The great thing is that you can use the overview from the Extension.xml where you configure your extension and that JDeveloper automaticly generates the Manifest file for you:


Next you need to configure your hook in the Extension.xml, this is where you define your Java class where the actual rule magic happens.


As said, the overview works pretty good to configure what you need in the extension.xml, but I will also give the xml snipped from the source:
    
        
                            
                
                
                    sample-category
                    true
                    warning
                
                
                     nl.olrichs.abc.audits.inn.IterCacheAnalyzer
                                
                
                    JSF
                
            
        
    

In the triggers section, you define your audit-hook, fill in the category that it belongs to, I choose a sample-category. Set the properties on the rule-definition, make sure you give it a good ID, set the severity and put it in the correct category. Next you define your analyzer class, this is the Java Class you need to fire the rule.
Last but not least you need to define a project technology as trigger.

Next we can define some properties in the resource bundle that will be picked up automatically (notice that the resource bundle is coupled to your extension by the extension.xml):


So lets look at the actual Java class that is defined in the audit-hook. First off all, this class needs to extend the oracle.jdeveloper.audit.analyzer.Analyzer.
Next you need to inject the rule into the analyzer:
    @ExtensionResource("nl.olrichs.abc.audits.rule-invalid-iter-cache")
    private Rule CACHE_RESULT_FALSE;

Now you can hook into different enter and/or exit methods. In this example I only need the enter method for the document and the exit on the attribute. The code is in the snipped below, see the JavaDoc section for functional explanation:
   
    /**
     * Enter a document.
     * Check to see if this is a pageDefinition file. If not, we can stop here.
     */
    public void enter(AuditContext context, Document document) {
        String firstNodeOfdocument = document.getDocumentElement().getNodeName();
        if (!"pageDefinition".equals(firstNodeOfdocument)) {
            setEnabled(false);
        }
    }

    /**
     * Enter an element, put the element on the context. 
     */
    public void enter(AuditContext context, Element element) {
            context.setAttribute(elementKey, element);        
    }

    /**
     * Exit an attribute, check if this element is inside an iterator.
     * If so, check if we're an cacheResult attribute and check the value.
     * Report the results back to the Editor.
     */
    public void exit(AuditContext context, Attr attr) {
        if ("iterator".equals(attr.getOwnerElement().getNodeName()) &&
            "CacheResults".equals(attr.getName()) &&
            "false".equalsIgnoreCase(attr.getValue())) {
            context.report(CACHE_RESULT_FALSE);
        }
    }

Now that the rule is set up, lets look at running and testing this rule. What I do first is deploy the extension to the current platform:


After this, you can deside to Run or Debug the extension by right clicking the project and select Run or Debug Extension. You will see that a new instance of JDeveloper gets started and you can test your extension in here.

In the newly started JDeveloper, you can make a final check in your preferences to see the rule. Here you can configure your Audit profile. Go to Tools -> Preferences -> Audit -> Profiles:

Here you should see the category that you filled into your resource bundle and under it the rule that your just created. Make sure the checkbox is enabled so it will run.

I created a fake pageDef with an iterator and the cacheResult property set to false. You see that the rule gets fired and the configured message from the resource bundle is shown. You also see the warning on the right top in the source editor:




Create your Selenium test reports with Ant

In the previous blog post I described how to JUnit test your Selenium tests. Once you have this set up, you can use Ant to run this tests and create a report about the results.

Since there are standard targets for JUnit and JUnitReport in Ant, the Ant file is pretty clean. We start with setting up our environment, including a clean target. The tool I use to display the XML on my blog makes it a bit messy, but you get the idea:












    
    
    
    
    
    



    

We set up the output directories, the reports will come in the reports directory. In the Lib directory, we put the selenium standalone jar file that is used to run the Selenium test in JUnit. As well as the JUnit jar to run the JUnit test itself.

After that there are two targets, prepare and compile:

    
     
    



    
    

In the prepare we set up the structure and create the directories that we need. In the compile we look for all the java sources in the src directory and compile them to the classes directory. Now all that is left is a target to run the JUnit and create the reports:

  
    
      
        
      
    
    
    
  
  
    
      
    
    
  

I choose not to split those two target, since I never want to run a test without creating the reports or vice versa. The JUnit runs all the tests that are in the classes dir, where the compile target puts his output, he runs the JUnit test using the classpath that is set up in the environment and puts this in the output directory.
After this the JUnitReport tasks picks up the reports from the output directory and creates a HTML structure off all the tests that are ran. This is how the index.html looks:

  
You see an overview of the tests, the failures and erros, all clickable to drill down for more information.
If you like you can browse through the packages & classes.

JUnit test your application with Selenium

We want to test our ADF application with Selenium. To get this working, we use the Selenium IDE (Firefox plugin) to record a session. You can export this recorded session to different formats, since we are mainly Java/ADF developers at our project, we choose to export to Java.

Because we build ADF applications with the JDeveloper IDE, this is the preferred IDE to build the JUnit test as well. In the Fusion WebApplication I created an extra Project called ‘SeleniumTest’.


To get it working, you need to have the JUnit extension, you can easily install this through the Help -> Check for update menu.
Next to that, you also need to add the selenium-server-standalone jar, to your project. You can download the latest version from the Selenium download page.

First we’re going to record a session with Selenium. Start your application, open it in firefox and open the Selenium plugin. After that click the record button.


Now just navigate to your application, in this example I got a form and a table, I click the next button two times navigating to the ‘Purchasing’ department. For this example we’ll keep the test clean and simple.


Stop the record session by clicking the record button again, you’ll see it has recorded the clicks.
If you want, you can replay it with the play button to check if it works.


Now export your file through the menu File -> Export -> Java / JUnit 4 / WebDriver.


Save this Java file in your SeleniumTest project, after this you need to rename your package in the java file. In this java class you see a few methods, we’ll focus on two off them for now, the setUp and testHr.

 @Before
  public void setUp() throws Exception {
    driver = new FirefoxDriver();
    baseUrl = "http://127.0.0.1:7101/";
    driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);
  }

Here the Firefox driver is initiated and the baseUrl is set.

  @Test
  public void testHr() throws Exception {
    driver.get(baseUrl + "/SeleniumAntJenkins/faces/untitled1.jspx");
    driver.findElement(By.cssSelector("#b3 > a.xg7 > span.xgf")).click();
    driver.findElement(By.cssSelector("#b3 > a.xg7 > span.xgf")).click();
  }

The testHr method is the actual JUnit test that get launched after the setUp.
There is one bug in this generated class. As you can see the baseUrl ends on a slash and the first line in the testHr method adds a slash. I prefer to change the baseUrl and remove the last slash behind the portnumber.

Now your test is ready to run.
Just right click the java class and run (or debug, as you prefer).


You’ll see that a FireFox browser is launched (with the text WebDriver in the right bottom). It follows the steps in your test case and closes the browser again. After that you see the green positive result in the JUnit test runner.


That’s all it takes to set up a simple JUnit test that does a functional (screen) test with the help of Selenium in the JDeveloper IDE.