Richard Olrichs: Extension

Showing posts with label Extension. Show all posts

New Release: ADF EMG Audit Rules

A new release of the ADF EMG Audit Rules has been out, version: 12.2.1.1.20170129.1659

You can find the artefacts on the download page here.

Or just use the Help -> Check for Updates function and find it in the Open Source section.

Resources:

New Release: SonarQube ojaudit plugin

There is a new release of the ojaudit plugin for SonarQube on github.
Version 2.0 of this plugin is now compatible with SonarQube 5.6 and 6.0.

For the release, please go to: https://github.com/adfemg/sonarqube-ojaudit/releases/tag/2.0

The sources can be found on github under adfemg: https://github.com/adfemg/sonarqube-ojaudit

ADF EMG Audit Rules 12.2.1 Released

The ADF EMG Audit Rules are now available on JDeveloper 12.2.1. I want to thanks to Alexis López for reminding me and helping me out!

If you go to Check for Updates, make sure you tick the 'Open Source and Partners Extensions' and click next:

You should see the 'ADF EMG Audit Rules' appear, tick them and click next:

Wait for the download and install, you should see the ADF EMG Audit Rules being installed:

Restart JDeveloper and you are good to go, happy coding!

ADF EMG XML Data Control version 1.0.0

Today at Oracle Open World, we (Wilfred and myself) officially announced the 1.0.0 version of the ADF EMG XML Data Control. Check out the presentation on slideshare if you missed it.

You can get this extension through the JDeveloper Help -> Check for Updates menu. Make sure you select the 'Open Source and Partner Extensions' checkbox:

There you should see the 'ADF EMG Data Control' extension:

A brief description for those who were not at our OOW Sunday Session:
The XML Data Control is an ADF Data Control that is used by developers to create data bindings in ADF Faces pages, just like the ADF BC Data Control and the POJO Data Control. The data exposed through this data control can be any XML source – from a BPM Human Task, from a SOAP or REST WebService, from a static XML document or a custom Java Class that produces an XML document from anywhere.

Read more on this project on our public wiki.

If you’re interested in following or contributing to this open source project, make sure you bookmark the following links:

The ADF EMG XML Data Control Extension is available for both JDeveloper 11gR1 and JDeverloper 12c.

ADF EMG Audit Rules moved to Atlassian

For those contributing and using the ADF EMG Audit Rules extension, this is now moved to the Atlassian Suite. Here we have better integration and more modern tools than on java.net.
Big thanks to Wilfred for helping me out with the conversion.

Make sure to save/bookmark the following links:
- Bitbucket
- Confluence / wiki
- Jira
- Bamboo

The old svn repository on java.net is deleted and you can now use git to connect to the repository on bitbucket. If you’re new to git I advise SourceTree from Atlassian as tool.

ADF EMG Audit Rules available on JDeveloper 12.1.3

I got a few questions from people why the ADF EMG Audit Rules are not available in JDeveloper 12.1.3. So there has been a new release of the ADF EMG Audit Rules. No new functionality is implemented this time, but the extension is now available for JDeveloper 12.1.3.

If you go to Help -> Check for Updates, tick the Open source and Partner Extensions checkbox and press Next:

Select the ADF EMG Audit Rules and click Next:

The extension ADF EMG Audit Rules should be installed correctly, click finish and restart JDeveloper 12.1.3:

Now if you go to your Tools -> Preferences, there is a button ‘Manage Profles’ on top of the Audit tab, you will find your profiles under that submenu. Press the button to open the Profiles menu:

Within the Audit Profile, you should see the ADF EMG Audit Rules appear:

New release of the ADF EMG Audit Rules

There is a new release of the ADF EMG Audit Rules extension. With this release there is now support for both JDeveloper11R1 and JDeveloper12c. However, remember that JDeverlop11g does not support the suppression of violations, so this may lead to a lot of violation on existing projects.
Remember that you can define a custom profile in the Audit tab under preferences to unselect certain rules, but off course it is better to look at the warnings and see if you can fix them.

In this new release we also improved the stability of the extension, but if you see unexpected behavior in JDeveloper and you suspect it comes from the ADF EMG Audit Rules extension, you can file an issue in Jira. The amount of rules went up from 18 in version 1.0 to 35 audit rules in version 2.0.

Next to Wilfred I would also like to thanks Rohan Walia for his time and commitment to this project!

If you would like to help out and get involved in this project, check out the Index page with various links to documentation, blogs and the open source project on java.net.

Manually clear your JDeveloper cache

Recently I’ve been working more and more with JDeveloper Extension Projects. When working with Extension Projects, you deploy to your target platform a lot. I’ve noticed that sometimes, your JDeveloper Platform gets confused with this and the extension you’re working on doesn’t load correctly.

For example, you deploy your extension to the target platform, you follow this deployment in the log file and you see it got deployed successfully. After this, you debug the extension and wait for JDeveloper to start up. However, when trying to debug the extension, you notice something isn’t working.

While working on the ADF EMG Audit Rules extension, I noticed that sometimes none of the rules where configured in the Audit menu under Tools -> Preferences. This means that the whole extension wasn’t installed correctly.

The easiest way to solve this, was for me to clear the JDevelopers cache manually. To do so follow the following steps:

First close your JDeveloper, to make sure JDeveloper doesn’t lock any files. Then go to your Oracle_Home where you installed JDeveloper. There is a subfolder \Oracle_Home\jdeveloper\jdev\extensions:

In here, locate the extension you’re working on, and delete this jar file. In my case this was the ADF EMG Audit Rules extension.

Next navigate to your JDevHome and go into your system folder of JDeveloper:

In here you see your installed extensions, but you should be able to locate a system_cache directory as well. Delete this whole directory.

After deleting this directory, go deeper into the system folder. You should be able to find the following location:

This is the system_cache of the JDeveloper you start when clicking 'Debug Extension', delete this system_cache folder as well.

After deleting these directories, startup JDeveloper again and open your project. Don’t forget to deploy to the TargetPlatform again and after this run or debug your extension.

This should’ve done the trick and you should be able to run your extension again. However, during the last few weeks, it happened to me one time that even this didn’t help and I had to delete the whole system folder instead of only the system_cache.

You can delete this folder without any problems, because JDeveloper will recreate it for you, but you will lose your settings, preferences and configurations you made to JDeveloper or the integrated WebLogic server.

Distribute your Extension with an JDeveloper Update Center

If you created an extension project, you can share this with others by creating a zip file. However, there is a powerful mechanism in JDeveloper called Update Centers. This blog will show you how you create an Update Center to share your own Extension Projects.

I’ll use my workspace from this blog about Audit Rules as example. Step 1 is creating an bundle.xml within your Project source. The bundle.xml should like like this:


    
        Audit Rules
        1.0
        Richard Olrichs
        http://www.olrichs.nl

In this XML file you configure some properties about your extension, like the name, author and the requirements. Most of this information you already configured in the Extension.xml as well.

After this we need to create a new deployment profile. Go to your Project Properties, create a new Jar File deployment Profile. In the jar options, change the extension from .jar to .zip:

Go to your Profile Dependencies and tick the Project:

Now there are a few steps you need to take in the File Groups section:

First select the predefined Project Output and press Delete
Select the File Groups again and press New:

Enter ‘Extension Jar’ as name and choose ‘Libraries’ as Type.
Go to the Contributors under Extension Jar and make sure the jar file is selected.

Again select the File Group and press New:

Enter bundle.xml as name and leave the Packaging as Type.
As Target Directory in Archive, enter: META-INF
Go to Filters under bundle.xml and deselect everything except the bundle.xml

The result should looks like this:

Now press OK to exit the properties. Right click your Project, select deploy and select the newly created deployment profile. This should result in a zip file being created by JDeveloper:

We’re now done with creating the zip file and bundle. You could share this zip and let other people install it on their JDeveloper. However, we rather distribute this through an update center. Typically, you want this zip file on a network drive or on the web, but in this example we’ll leave it locally on the computer. The general idea is the same.
Now we’re going to create the update center, this is a simple XML file, you can create this anywhere on your file system.


     
        Audit Rules
        1.0
        Richard Olrichs
        http://www.olrichs.nl        
        
                        
              
        URL_TO_JWS\Extension\deploy\DeployExtensionZip1.0.zip

It looks a lot like the bundle.xml that we created, with the exception of a location being presented as bundle-url. This is pointing to your zip file, in this case I left the zip file in the deployment folder.
Now, when you go to Help -> Check for Updates, you can add a new Update Center:

Enter a name and browse to the created XML file and click OK.
After this, unselect the Oracle checkboxes and only check your own update center and click Next:

You’ll find your extension here, if you click next, you see it is under the New installs. Now press Finish and after the popup for a Restart press Yes. After JDeveloper has been restarted, your plug-in has been installed.

Now we can have a look at the power of creating an update center over sharing the zip file. Imagine you’ve been working on your extension for some time and want to create a 2.0 version. The steps involved here are:

Update the bundle.xml.

Update the bundle version to 2.0.
Update the version of the update to 2.0.

Redeploy to create a new zipfile (also a 2.0 version).
Update the UpdateCenter XMLfile to be in sync:

Update the version of updates
Update the version in update
Update the bundle-url to point to the 2.0 zip.

Next we go back to the Check for Updates menu. Select our update center and unselect the others and press Next:

Here we see the new version of our Audit Rules, version 2.0.

Now, without distributing the new zip file again, anyone who has installed the update center, will be able to get the 2.0 version of your Extension project.

Index page for Audit Rules

Over the last few weeks, I gathered and produced more and more info about Audit Rules, JDeveloper Extension Projects and other stuff related to creating Audit Rules.

I thought it might be wise to create some sort of an index page to refer to all these blogs, guides, articles and so on …

I will try to keep this page up to date.

Oracle Documentation:

By the Community:

Open source projects on java.net:

Interesting Reads:

Published on www.olrichs.nl:

Feel free to let me know if I missed anything.

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.

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:

Richard Olrichs

Pages