JDeveloper: Controlling which Resources (Files) are Copied into the Projects Output Directory

Some projects need resource files available in the output directory together with the class files. This is a fairly common task, however it’s not obvious how to archive this for all types of resources.

IF you never have had the problem, that a resource file you used in your project did not turn up in the output directory, you probably have used only default resource files like ‘properties’, ‘wsdl’ or ‘XML’ files. These files are copied into the output path by default.

Lets assume you have a resource e.g. a tiff file (*.tiff) or a TrueType font (*.ttf) which you need in your project and finally in the jar or adflib you build from the project. Lets add a dummy file ‘MyFont.ttf’ in a new folder named ‘res’ under the base path of the model projcect ‘de.hahn.blog.controlresourcefiles’. After this the model application looks like

Model Project after adding Font File

No problem with this. Now if you compile the model project and check the output path Q:\QT\BlogControlResourceFiles\CRFModel\classes in this sample, you’ll notice that the folder ‘res’ and file ‘MyFont.ttf’ is not in the directory tree

Output Path after Compile

If you check the path configuration of the project, it shows that the folder and the file should have been there

Project Path

Well, the problem is an other configuration for the project. If you check the compiler node in the project properties you see that there is a filter which defines which file types are copied into the output path of the project

Project Compiler Settings

As you see there is no entry for type ‘.ttf’ which means that files with this suffix are not copied into the output directory. The solution to the problem is to simply add the suffix ‘.ttf’ to the filter and compile the project again. After this the file ‘MyFont.ttf’ can be found in the projects output directory.

If you have any resource of a type (file suffix) you want to automatically copied into the projects output directory, you simple add the missing suffix to the filter.

JDeveloper 11.1.2.2.0: First trap when installing a new JDeveloper version

One of my tasks is to evaluate new JDeveloper versions. I have to say that it’s one of the tasks I really do like as I get the chance to try out new things . OK I have to check if current applications are still running first.

I started installing JDev 11.1.2.2.0 on my development machine, checked out the sources of the current applications and started compiling them and building adf libraries. At one point I got the below error message:

Error: An unreported error occurred in Appc. No errors were reported, but the tool returned a failure result code: 1.
Warning: <11.05.2012 16:40 Uhr MESZ> <Error> <J2EE> <BEA-160141> <Could not initialize the library C:\..\..\..\oracle_common\modules\oracle.jsf_2.0\jsf-ri-20.war. Please ensure the deployment unit is a valid library type (war, ejb, ear, plain jar). \..\..\..\oracle_common\modules\oracle.jsf_2.0\jsf-ri-20.war (Das System kann den angegebenen Pfad nicht finden) with : \..\..\..\oracle_common\modules\oracle.jsf_2.0\jsf-ri-20.war>
Warning: <11.05.2012 16:40 Uhr MESZ> <Error> <J2EE> <BEA-160187> <weblogic.appc failed to compile your application. Recompile with the -verbose option for more details. Please see the error message(s) below.> 
Warning: [J2EE:160147]One or more libraries could not be processed. See error above.

Interestingly the message complains about a war file ‘jsf-ri-20.war’ at a location which I never use for JDev. I never install JDev on drive C on a Windows system. All applications are installed on a different drive (P in my case). The reason for this is the the ‘system11.1.2.2.39.61.83.1′ folder was created in my personal ‘application data’ folder which resides on drive C. As this path has spaces on my Windows system I normally move the ‘system11.1.2.2.39.61.83.1′ on drive P. To archive this I set the environment variable JDEV_USER_DIR to ‘P:\jdeveloper\system’. When starting JDev the next time the ‘system11.1.2.2.39.61.83.1′ is generated in the folder ‘P:\jdeveloper\system’.

After this change I tried again and got the same error, only this time the path started with ‘P’. The path to the jar file C:\..\..\..\oracle_common\modules\ made me think again. This path is normally part of the ADF Runtime installation on a WLS server. In this case the integrated WLS which comes with JDev.

Well, at the time I tried to compile a project containing an ADF Task-Flow into an adf library. Interestingly the rebuild process somehow needs access to the ‘jsf-ri-20.war’. Problem is that I had not created the integrated WLS. This is done the first time you start the integrated WLS (debug or normal).

After starting the integrated WLS the first time the path gets created and my ADF Task-Flow compiles OK.

I installed JDev in various version hundreds (more or less) of times but never stumbled upon this.

JDeveloper: Case Insensitive Search and Performance

A couple of days ago Frank Nimphius published a new ADF Insider Essential video about Search Forms Customization where he also showed how to implement case insensitive searches. While the tip how to do this is fine, he did not mention the bottleneck involved in doing so. Yesterday, while writing up this blog I came across this blog ‘ADF ViewCriteria performance impact’ by Raman Nanda who summarized the same issue. The last statement in his blog is the starting of this blog:

Note:Also don’t choose to ignore null values for predicates that are required and create proper indexes on the table structure depending upon how you filter results. For ex: If predicate is upper(ename)=upper(:bvar) then create a index on upper(ename) .

Lets start with a look on a view criteria definition in JDeveloper 11.1.2.1.0. the image below shows the definition of a simple view criteria to search for employees who’s names start with a given bind variable. When you first add items to the view criteria both check boxes ‘Ignore Case’ and ‘Ignore NULL Values’ are checked.

ViewCriteria Definition: Ignore Case and Ignore Null

A close look at the ‘View Object Where Clause’ part reveals that the ‘Ignore Case’ part of the query is not visible in JDev 11.1.2.1.0. This is a bug which I’m going to file in the near future. Before going into detail with the query lets uncheck the ‘Ignore NULL Values’ to see the final criteria:

ViewCriteria only 'Ignore Case'

Running the application module in the tester reveals the final query as (copied from the log window)

[104] SELECT Employees.EMPLOYEE_ID,         Employees.FIRST_NAME,         Employees.LAST_NAME,         Employees.EMAIL,        
             Employees.PHONE_NUMBER,         Employees.HIRE_DATE,         Employees.JOB_ID,         Employees.SALARY,         
             Employees.COMMISSION_PCT,         Employees.MANAGER_ID,         Employees.DEPARTMENT_ID,         
             Employees.ACTION_COMMENT 
             FROM EMPLOYEES Employees 
             WHERE ( ( ( (UPPER(Employees.LAST_NAME) LIKE UPPER( :bindLN || '%') ) ) ) )
[105] Bind params for ViewObject: [de.hahn.blog.vcinsesitivesearch.model.dataaccess.EmployeesView]VCISAppModule.EmployeesView1
[106] Binding param "bindLN": K

Here you see that the ‘Ignore Case’ results in calling SQL UPPER’(…) on the bind parameter as well as on the row attribute. When you copy this query and run it in a SQL worksheet it returns the right results. However, in this bog we are more interested in the execution plan of the query. This is shown in the below image:

Execution Plan Without Index

The interesting thing is that the result is reached by a full table scan, which you see as the option is ‘FULL’ for table access. This is not a problem if the table contains only a small number of rows, but if you work on large tables with 10000+ rows it’ll take ages (OK, it’s notable longer then you would expect) to execute.
If you only have defined the normal index on the LAST_NAME column

create index normal_ln_idx on employees (last_name);

the plan doesn’t change at all. This is exactly what Raman Nanda meant in his blog. You need to create a function based index on the LAST_NAME column. Here is the SQL to do so:

create index upper_ln_ix on employees (UPPER(last_name));

Running the query again after creation of the new index results in

Execution Plan with UPPER Index

As yo ucan see the table now is accessed via the ‘upper_ln_ix’ index we created. This speeds things up in large tables.

To summarize this blog: you should, as part of your testing, check the execution plans of the queries executed by your application. This can result in a huge improvement of the performance. You should ask your DBA to help you with this task. There are tools readily available to the DBA to help getting information about the queries executed by your application.

JDeveloper 11.1.1.6.0 aka Fusion Middleware 11gR1 – Patch Set 5 is available: First Impression

Tweets, blogs articles are coming from all directions as the next ‘bug fix’ release of JDeveloper has gone public.

I’ll skip the download and install stuff for now, as there are some posts on this already. First thing I normally do is to read *all* documentation (just kidding). Well, I at least read the Release Notes and What’s New documents.

First thing which caught my eyes was the Deployment section. Here I find that JDev 11.1.1.6.0 internally uses a WebLogic Server of version 10.3.5. Still we need to set up an WLS 10.3.6 instance for testing as the next sentence states:

If you want to configure a WebLogic Server 10.3.6 domain to test an ADF application , you will need to install WebLogic Server 10.3.6 and use the 10.3.6 JRF template to add the ADF runtime libraries.

To verify this I installed JDev 11.1.1.6.0, deployed my ADF Version WebService onto the freshly build integrated WLS instance:

JDev 11.1.1.6.0 integrated WLS instance

and here is the result of the ADF Version printout

ADF Version JDev 11.1.1.6.0 integrated WLS instance

This made me think about the convention that applications developed with JDev version 11.1.1.x should run on a WLS version 10.3.x, where x should be equal for JDev and WLS. This statement still is true (I guess) for all environments beside JDev development.

I’ll hope we don’t find a use case where this WLS version mismatch is the cause of error.

UPDATE:
Chris Muir blogged about this version mismatch between JDev and WLS here https://blogs.oracle.com/onesizedoesntfitall/entry/adf_runtimes_vs_wls_versions

JDeveloper: Way to show a Version Number in the UI

My last presentation at the German ADF Partner Community showed how to put a version number into an application ear and allows two versions of the same application to exist on a managed WebLogic Server. One question I got from the audience was how to show this version in the UI of the application. This blog post shows one way of doing this.
For those readers which do not know how to put a version number into an application EAR before deploying it to a WLS, lets start with this.
Andrejus Baranovskis has a blog post How to set EAR Version for ADF Application on WebLogic about this which uses a more hand coded approach. Edwin Biemond showed a small ant script to do is. I will show you a different solution using ANT.
This solution consists of a general GeneralVersionBuild.xml ANT script and a project dependent VersoinBild.xml ANT script which sets some properties (the version properties) for the GeneralVersionBuild.xml. The GeneralVersionBuild.xml defines the targets to alter the different version numbers you define for your applications and print out the version in the log like

Versioninfo:
     [echo] VERSION: V1.0.0.3 DB.V1 vom 2012/02/12 21:09
     [echo] Major: 1
     [echo] Minor: 0
     [echo] Fix: 0
     [echo] Build: 3
     [echo] Date: 2012/02/12 21:09
     [echo] DB-Schema Version: 1
     [echo] --------------------------------------------------------------------------------------------------

The information above is the complied from the version.properties file which defines the different parts of the version number:

#Build version info
#Sun Feb 12 16:06:18 CET 2012
DBSchema=1
majorVersion=1
fixVersion=0
minorVersion=1
buildDate=2012/02/12 16\:06
buildNum=39

To manipulate the properties we use the targets defined in the GeneralVersionBuild.xml ANT script. This is called by the project dependent VersionBuild.xml ANT script:

<?xml version="1.0" encoding="UTF-8" ?>
<project name="AVIVersionBuild" default="make" basedir=".">
    <!-- # Relativ path to the base of the application -->
    <property name="root.dir" value=".."/>
    <property name="earFileBaseName" value="BlogAccessVersionInfo"/>
    <!-- PATH TO VERSION.PROPERTIES FILE (e.g.: src/de/hahn/blogxxxx/view/version.properties) -->
    <property name="file.version.properties" value="src/de/hahn/blog/accessversioninfo/view/version.properties"/>
    <property file="${file.version.properties}"/>
    <property name="deployFolder" value="../deploy/"/>
    <!-- PATH TO THE GENERAL VERSION BUILD ANT SCRIPT -->
    <import file="${root.dir}/Versionierung/GeneralVersionbuild.xml"/>
</project>

All we need to do is to set the Versionbuild.xml file as ANT’Project Buildfile’ file

Setup Ant Project Buildfile

Now that the project has a version.properties file (at src/de/hahn/blog/accessversioninfo/view/version.properties) holding information about the current version of the application we need a way to access this information on a page in the UI. As we are using a property file we can bind this file as resource bundle into the project and access the parts (properties) with EL.
To add the version.properties file as resource bundle we open the project properties, select the ‘Resource Bundle’ node and then set the properties from the bundle as outputText onto the page.

Make sure that you select the right project when you add a property file.

Add a property file as bundle

Next search for the version.properties file in the project

Select version.properties

Now in the page we can access the property via EL. We drag an outputText component on the page and select its value from Resource bundle

Select a value from resource bundle

Select value from property file

This will create this entry in your page

<c:set var="aviviewcontrollerBundle"
   value="#{adfBundle['de.hahn.blog.accessversioninfo.view.version']}"/>

and here is the resulting outputText:

<af:outputText value="Version: #{aviviewcontrollerBundle.majorVersion}.#{aviviewcontrollerBundle.minorVersion}.#{aviviewcontrollerBundle.fixVersion}.#{aviviewcontrollerBundle.buildNum} from #{aviviewcontrollerBundle.buildDate}" id="ot6"/>

and the resulting page when you run the application

Running application

As you see the name of the resource bundle is set to ‘aviviewcontrollerBundle’ (the default bundle name). This happens if you don’t already have a default bundle defined which contains a key value pair. You can rename it to e.g. ‘versioninfo’ to make clear what the bundle is used for. In this case you have to change the EL to access to properties too.

<c:set var="versioninfo"
value="#{adfBundle['de.hahn.blog.accessversioninfo.view.version']}"/>
…
<af:panelGroupLayout id="pgl2">
<af:outputText value="Version: #{versioninfo.majorVersion}.#{versioninfo.minorVersion}.

Save (most of) your changes to the JDeveloper IDE

Under some circumstances you may need to rename or remove your system11.x.x.x folder to overcome errors with the IDE which can’t be solved otherwise. I blogged about this How to find and reset the system11.x.x.x folder for a JDeveloper installation.
However, this means that you loose all of the changes you made to IDE, e.g. connections to DBs, code templates and many more.
In the current version or JDeveloper there is no feature to save all the changes you made with a simple export or click on a button. An ER for this is about to be filed.

Until we see this ER implemented you need to store the changes you made yourself. First of all we need to know all the places were changes can be saved in a file or exported into a file. I put all those files under source control. This makes them available for other developers in the same team and allows to hold different configurations for different or the same JDeveloper version. This blog post lists all the places I know. If you know any other place, please drop a comment so that I can include it here.
To my knowledge the locations below are working for all JDeveloper version from 11.1.1.x up to the current version 11.1.2.1.0.

There are three locations where you can save your changes

1. Recource Palette
2. Preferences
3. File menu

Lets start with the Resource Palette:

Resource Palette 1

This will bring up

Resource Palette 2

This dialog allows you to save all the connection to DBs and Weblogic Servers you have defined as well as Catalogs. All you have to do is to specify a path and a file name to store the information.

Next are the Preferences. Here are a couple of places where you can export your changes.
Audit Profiles:

Audit Profiles

Code Editor – Code Style

Code Editor - Code Style

Code Editor – Code Templates

Code Editor - Code Templates

Code Editor – Syntax Colors

Code Editor - Syntax Colors

Database – SQL Formatter

Database - SQL Formatter

Database – SQL Formatter – Oracle Formatting

SQL Formatter - Oracle Formatting

Database – SQL Formatter – Other Vendors (each vendor can be saved)

Database - SQL Formatter - Other Vendors

Shortcut Keys

Versioning – Comment Templates

Versioning - Comment Templates

Finally the ‘File’ menu which mainly allows to export the connections to the source control system you use

File - Export