Andreas

Resolving build dependencies through manifest file

The MANIFEST.MF file in a jar file can be used to define runtime dependencies through the Class-Path attribute. In the manifest specification, it says:

Class-Path: The value of this attribute specifies the relative URLs
of the extensions or libraries that this application or extension needs. 
URLs are separated by one or more spaces. 
The application or extension class loader uses the value of this attribute
to construct its internal search path.

Since it explicitly states “application or extension class loader”, it is not completely clear from the specification that the Class-Path attribute is also considered by the javac compiler to resolve build dependencies. However, it is – this is the bug which introduced that feature in Java 5: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4212732 Consider the following sample code which imports classes from some third party jar files:

package com.example;

import org.apache.log4j.PropertyConfigurator;
import com.google.gson.Gson;

public class Sample {

   public static void main(String[] args) {
      PropertyConfigurator.configure("log4j.properties");
      Gson gson = new Gson();

      // ...
   }
}

We can create a jar file like libs.jar with a Class-Path reference to the corresponding libraries:

$ cat manifest.txt
Class-Path: lib/gson-2.2.2.jar lib/log4j-1.2.17.jar

$ jar cvfm libs.jar manifest.txt
added manifest

By simply adding the libs.jar to the classpath when invoking javac, the additional jar files get pulled in:

$ javac -d bin -classpath libs.jar -sourcepath src src/com/example/Sample.java

$ ls -la bin/com/example/Sample.class
-rw-r--r-- 1 andreas users 432 Apr  7 12:20 bin/com/example/Sample.class

A real-world sample where this is used is the Oracle Platform Security Services. There is only one jar file which needs to be added to the build path, jps-manifest.jar, which references all other required jar files through its Class-Path attribute.

Passing string parameters to a SQL*Plus script

With SQL*Plus, it is possible to use parameters in the form &1, &2, … inside a script to be executed through the sqlplus command and pass the parameter values from the command line. Consider this script, contained in a file called sample.sql:

SELECT '&1' FROM DUAL;

This script can be executed from a unix shell using sqlplus as follows:

$ sqlplus user/pass@instance @sample.sql Hello
...
old   1: SELECT '&1' FROM DUAL
new   1: SELECT 'Hello' FROM DUAL

'HELL
-----
Hello

Now, it is also possible that the parameter is not quoted inside the script:

SELECT &1 FROM DUAL;

If we execute this script in the same way as before, SQL*Plus simply inserts the parameter into the SELECT statement and it is finally treated as identifier:

$ sqlplus user/pass@instance @sample.sql Hello
...
old   1: SELECT &1 FROM DUAL
new   1: SELECT Hello FROM DUAL
SELECT Hello FROM DUAL
       *
ERROR at line 1:
ORA-00904: "HELLO": invalid identifier

To really pass the parameter as String, we need to properly escape it on the command line, using double quotes, single quotes and both of them need to be escaped:

$ sqlplus user/pass@instance @sample.sql \"\'Hello\'\"
...
old   1: SELECT &1 FROM DUAL
new   1: SELECT 'Hello' FROM DUAL

'HELL
-----
Hello

Note that using parameters this way should always be taken with care, so that no sql injection security issues are introduced!

List binding for selectOneChoice

In order to add a drop down box with a list of selectable values inside an af:tree or af:treeTable cell, an af:selectOneChoice component can be used:

<af:selectOneChoice id="soc1" 
                    value="#{node.bindings.ForeignKey.inputValue}"
                    autoSubmit="true">
    <f:selectItems id="si1" value="#{bindings.SelectionList.items}"/>
</af:selectOneChoice>

The two important attributes are the value attributes:

  • On the inner f:selectItems element, it defines the list binding which delivers the list of values to show in the drop down box.
  • On the af:selectOneChoice element, it defines the foreign key attribute from the current row (determined by node or row as set in the var attribute of the af:table or af:treeTable) which references the corresponding primary key from the selection list. The mapping between the foreign key and the primary key attributes is defined in the list binding in the respective pageDef file.
Now, there is one important detail to know about this list binding: When it is created automatically by JDeveloper when dragging an attribute from the Data Control panel onto the jsf page, the IDE automatically adds the attribute SelectItemValueMode="ListObject" to the list binding definition. This is absolutely crucial for the list binding to properly map foreign keys to primary keys. Without this attribute, the mapping is not done through the key mapping, but through the index of the entry in the selection list – thus, foreign key 2 would map to the second entry in the selection list (SelectItemValueMode="ListIndex" which is also the default if the attribute is missing). Now, the point is: This attribute is not added to the binding if we create the list binding manually through the bindings editor. The dialog which is shown when manually creating the list binding also does not provide the possibility to select one or the other value for the attribute. So, if we have created the list binding manually (which is sometimes convenient), it is automatically in mode SelectItemValueMode="ListIndex". In order to change it to ListObject, we need to manually change it in the property editor (or in the XML source code)! The same, by the way, happens for the DTSupportsMRU attribute of the list binding – when the binding is added by the IDE through drag&drop from the data control panel, this attribute is added automatically so that the list binding supports most recently used entries. When created manually through the binding editor, the attribute is not added – you need to add it manually in the XML code after the binding has been created.