Extension Intermission #1 - Subversion Monitor, Extension to monitor a Subversion repository

Introduction

There are at least a couple of utility programs that will let you monitor the commit activity on a Subversion repository both running on the Windows platform. Here is a third one, appropriately baptized Subversion Monitor, developed to run - of course - as a JDeveloper extension.

Main Theme

Installation

To install Subversion Monitor, first download the SubversionMonitor.zip file from the link below and save it somewhere in your computer. Then start JDeveloper - it was developed and tested with the Studio Edition Version 11.1.1.2.0 version of JDeveloper - and select Help | Check for Updates... to bring up the Check for Updates dialog. Chose Install From Local File and then click on the Browse... button to browse for the SubversionMonitor.zip file you just downloaded.

Click Next to proceed with the installation and in the Summary page click Finish. JDeveloper needs to re-start to finalize the installation, so in the Confirm Exit dialog that is presented click Yes.

Setting up

Upon re-starting, JDeveloper should load the Subversion Monitor extension and notify you that it is unable to connect to the Subversion repository.

This is OK. You will need to setup the Subversion repository url along with your Subversion credentials. To do this, select Preferences from the Tools menu to bring up the Subversion Monitor Preferences dialog.

Enter your Subversion repository URL, username and password in the dialog and uncheck the Disable Monitoring check-box. This will enable a timer to notify you when there is a new revision in your repository. Set the timer delay appropriately with the Monitor Repository Every (seconds) spinner. When done, click OK to see Subversion Monitor in action!

You can bring up the notification balloon on demand anytime by clicking on the team icon on the status bar. To disable the timer monitor, check the Disable monitoring check-box on the balloon. You can review the latest revisions by clicking anywhere else on the notification balloon. Doing so will bring up the Revisions editor.

As you click on the revision in the Revisions table, the files that were changed for that revision will be displayed in the Revision Files panel at the bottom. The M flag in front of the file is the action on the file and it can be any of the M(odified), A(dded), D(eleted). You can set the number of top revisions to view using the Maximum Revisions to View in Editor spinner in the preferences page.

As a final note, Subversion Monitor does not require that you configure versioning for Subversion in JDeveloper.


[Amended on May 17th, 2010]
Subversion Monitor is now available directly from the Open Source and Partners Extensions of the JDeveloper Help | Check for Updates... feature!

Conclusion

Enjoy monitoring your colleagues as they commit their changes using Subversion Monitor! Your comments, suggestions (, bug reports) are welcomed.

Until the next time, keep on JDeveloping!


Extension

SubversionMonitor.zip

FAQ #21 - How to passivate/activate ADF Application Module class instance variables

Introduction

If you are using instance variables in your Application Module (AM) class, as part of some algorithm in your application and you expect these variables to persist from one user request to another so that the algorithm works as expected, passivation (and activation) support for these variables must be added. This FAQ will show you how to do this and at the same time build a "mini sub-framework" to avoid duplication of the basic passivation-activation code that you must write for all your AMs in your project.


Main Theme

Some Introductory Information

Application Module pooling is the process of acquiring an AM from and releasing it back to a pool. This pool of AMs contains a limited number of AMs defined in a configuration file. When all AMs have been associated with user sessions, an already-used AM must be re-used. For this to happen, the existing data associated with the AM must be saved. The passivation process saves information used by the AM into the passivation store -  usually a database, while the activation process does exactly the opposite, restores the state of the  AM from the passivation store. The information is saved as an XML document. Take a look at FAQ #14 - How to test an Application Module for activation-safe in ADF 11g for additional information regarding the passivation and activation processes.

You can add custom passivation and activation logic in your AM class by overriding the ApplicationModuleImpl methods passivateState() and activateState() respectively. The passivateState() method should create the necessary XML elements for each AM instance variable that you need to passivate. The activateState()  method should detect the specific XML elements that identify the instance variables in the passivated XML document and restore them back into the instance variables.


A "mini sub-framework" for passivating/activating Application Module instance variables

If you are using multiple AMs, you can avoid code duplication of this basic implementation of the passivateState() and activateState() methods by putting it in a base AM class. Then derive all of your other AMs from this base AM. The base AM class can then provide activation/passivation "triggers" to which the derived AMs can respond. The implementation of passivateState()  in the base AM should look like this:

As you can see, after calling super.passivateState() to allow the framework to do its own processing, we call onStartPassivation() to signal derived AMs that a passivation process is taking place. Derived AMs should override onStartPassivation() in order to provide a list of the identifiers - each identifier tied to a specific instance variable - to be passivated. Below is an example implementation of onStartPassivation() by a derived AM class. 

In this case a single passivation identifier call EMPLOYEE_LIST_ID is returned to indicate a list of Employees class instance variable.

passivateState() then loops for all passivation identifiers, creates an XML node for each identifier in the XML passivation document and calls onPassivate() passing the passivation identifier as an argument to it. A  derived AM will override this method in order to return the passivation data for the specific passivation identifier. An example implementation is shown below:

In this case the passivation identifier is checked and if it matches the expected identifier, the passivation data is supplied. 

Finally, passivateState() calls onEndPassivation()  to indicate the end of the passivation process.

The reverse process of activation is similar. activateState() calls onStartActivation() to get the activation identifiers. It then loops looking for each activation identifier in the activated XML document. If the identifier is found, calls onActivate() supplying the activation data along with its activation identifier as arguments. The derived AM can identify the instance variable being activated - based on the activation identifier, and restore it.

To test the framework, bring up the Edit Business Components Configuration dialog and  disable Application Module Pooling as it shown below. You do this by right-clicking on the AM in the Application Navigator and selecting Configurations... Then you click on Edit... to edit the specific configuration.

 This will in effect initiate a passivation-activation cycle for each request when the application is running. Finally save the configuration, enable debug logging on the console and run the application. You should see your AM class instance variables being activated.

To further explore this framework, the source code is supplied below.

Conclusion

If you are using class instance variables in the BC layer and you want their values to persit from one request to another, then passivating-activating these variables becomes necessary. The ADF BC framework allows you to do this by overriding the passivateState() and activateState() methods.

Until the next time, keep on JDeveloping!

Code

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

FAQ #20 - How to refactor ADF components in JDeveloper

Introduction

When it comes to refactoring ADF components in JDeveloper, most ADF developers come to know the refactoring features when they rename, move or delete Business Components (BC) objects. Yet fewer know that additional options exist in JDeveloper to refactor object attributes, attribute domain types, bindings, JSF pages and more.


Main Theme

Refactoring ADF BC objects

Refactoring ADF BC objects is available through the Rename... and Move... menu selections of  the Refactor menu. You can display the Refactor menu when you right-click on the BC component in the Application Navigation window.

If you choose to rename a component, JDeveloper will present a Rename dialog. In this dialog you can specify the new name for the object and choose to preview the changes that will be generated by the refactoring process.

It is a good idea to preview the changes, when the Preview option is available. When you click Preview in this case,  a Rename Log window will open listing all the changes that will be made by the refactoring process.

You can browse through the changes by clicking the Synchronize with Editor button This is a toggle button. It will open the applicable source file as you click through the changes in the Log window. When you are done reviewing the changes, click on the Do Refactoring button to apply the changes. If you decide for whatever reason not to go ahead with the refactoring, just close the Rename Log window.

Choose Move... from the Refactor menu to move the BC object to another package. This will present a Move dialog, where you can specify the new package name for the object to be moved.

Deleting a BC object is not available under the Refactor menu. It is available as a separate Delete menu option in the same context menu.

When you select Delete to delete a BC object,  a Confirm Delete dialog will be presented. If the BC object you are about to delete is used throughout the project, a Show Usages button will be also be available in the  Confirm Delete dialog and a Log window will open displaying all of the object's usages.

To view the object's usages on the Confirm Delete dialog itself, click on the Show Usages button.

To individually inspect each object usage, first click No to dismiss the Confirm Delete dialog. Then in the Log window click the Synchronize with Editor toggle button  and browse through the object's usages. As you browse through the object's usages, the corresponding source file will be opened and you will be positioned exactly where the object is being referenced in the source.

 Refactoring ADF BC Object Attributes

Refactoring ADF BC object attributes allows you to rename, delete and change the domain type of a BC object's attribute. Moving an attribute is not supported. To refactor an attribute, bring-up the object's overview editor by double-clicking on the object in the Application Navigator window and select the Attributes pane. Then right-click on the attribute and select Rename... or Delete from the context menu that is displayed.

In both cases - renaming or deleting the attribute, you can preview the usages - as described earlier before proceeding with the refactoring process. Consider also selecting Find Usages... from the context menu to review the attribute usages without doing any refactoring.

In addition to renaming and deleting an attribute, you can also refactor the attribute domain type by selecting Change Type.. from the context menu. This will display a Change type dialog from where you can select the new domain type for the attribute. You can also choose to preview the changes in the Change type Log window. This window will open when you select Preview and click OK.

Refactoring Data Bindings

You can refactor bound objects in the Data Binding Definition page. To do so, bring up the Page Definition File associated with a JSF page and in the Overview tab right-click on the specific binding that you want to refactor. Then choose Rename... or Delete from the Refactor menu.

Again, before you delete a binding you can verify its usages by clicking the View Usages button in the Delete Safely dialog that is displayed. This will open the Delete Safely Log window where you can review the usages. Click on the Synchronize with Editor toggle button  to bring up each usage into the source editor.

Refactoring JSF Pages

You can refactor a JSF page by right-clicking on the page in the Application Navigator and selecting Rename..., Move... or Delete from the Refactor menu. JDeveloper will update all references to the page in task flows and in the DataBindings.cpx mappings when renaming or moving the page.

Conclusion

The refactoring options in JDeveloper are quite powerful and can help substantially during the development process. They range from refactoring data components objects, object attributes, attribute domain types, data bindings, JSF pages and files. For more information about refactoring and their limitations I suggest that you check out the Fusion Developer's Guide - referenced below.

Until the next time, keep on JDeveloping!


Reference

Oracle® Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework 11g Release 1 (11.1.1) Part Number B31974-02