Query XML with namespaces in Scala

When processing more complex XML, the notion of the namespaces as part of elements and attributes becomes increasingly important. In Scala, this is actually quite easy. Imagine the following XML:

import scala.xml._
val a = <a xmlns:ns1="www.ns1"><b/><b/><b/><ns1:b/></a>

A standard query would return simply all b elements:

a \ "b"
res0: scala.xml.NodeSeq = NodeSeq(<b xmlns:ns1="www.ns1"/>, <b xmlns:ns1="www.ns1"/>, <b xmlns:ns1="www.ns1"/>, <ns1:b xmlns:ns1="www.ns1"/>)

To query for the specific namespace, two options are possible. The first option:

a \ "b" filter (e => e.namespace == "www.ns1")

Another option is to use Scales (untested):

val ns = Namespace("www.ns1")
a.asScala \* ns("b")


Scala XML attribute parsing

I really like the Scala XML capabilities. However, the parsing of attributes requires some additional care. Consider the following example:

val data = <doc>
<entry id="myid1">
<text id="YYYYYYY">"A"</text>
</entry>
<entry id="myid2">
<text id="XXXXXXXX">"A"</text>
</entry>
</doc>

With the single backslash \ accessing the elements without traversing and the double backslash \\ traversing, access to all id elements seems feasible with the following code:

Console println data \ "entry" \ "@id"

Unfortunately, this call will not return the desired values. The reason is that the class of scala.xml.NodeSeq does contain the projection functions, but not the attribute function (which is part of scala.xml.Node). While this will work on single XML elements, in this case the Seq of elements prevents this access.

Console println (data \ "entry").getClass

Thus, the following lines will give all id’s of <entry> nodes:

(data \ "entry").foreach(Console println _ \ "@id")
Console println (data \ "entry").map(_ \ "@id")

Alternatively, if all id’s of sub-elements shall be included, the code becomes easier again:

Console println data \ "entry" \\ "@id"


Eclipse 4 RCP launching with updated application model

Sometimes changing the application model (Application.e4xmi) of a RCP application does not seem to result into any change once a restart of the product is performed. For example an application starts successfully with one window, but after adding another Trimmed Window to the model, a restart does still show only one window.

The issue seems to be a persisted state in some of the runtime folders Eclipse creates (under the main tab of the run configuration, typically in the form of ${workspace_loc}/../runtime-Todo.product). By deleting these folders, the changes should now be reflected.

This can be performed automatically as well by simply adding -clearPersistedState to the Launching Arguments of the product configuration (tab Launching). Found here: Eclipse bug report 389651

Using OSGi services within an Eclipse RCP application

An existing Eclipse RCP application may use an OSGi service by simply implementing the following steps:

1. Create a folder OSGI-INF in the RCP application
2. Create a component.xml (in Eclipse, simply right click the OSGI-INF folder and choose “New” – “Component Definition”)
3. Ensure the component.xml is referenced as “Service-Component” by the MANIFEST.MF file (e.g. by an entry like “Service-Component: OSGI-INF/*.xml”)
4. Add the corresponding service bind and unbind references for the consumer class of the referenced service

In cases where the OSGi service provider does not bind the service when the consuming plug-in is running, several issues may be present:

• The product or launch configuration does not include the provider plug-in.
• The service provider’s plug-in does not get started. Eclipse run configurations typically have the “Default Auto Start” set to false. By either explicitly starting the service provider’s plug-in or by setting the service provider to use a lazy activation policy (preferred), this can be resolved. Simply add “Bundle-ActivationPolicy: lazy” to the MANIFEST.MF file.
• The service consumer plugin does not have a lazy activation policy. Although I don’t exactly understand why this needs to be the case, in certain scenarios it just does not seem to work.

Additional reading: OSGi design

Jar files and Eclipse RCP Plug-in

There are many ways to create a plugin project that contains the jars of a required library. The easiest is to simply:

1. Go to the “Plug-in Development” Perspective
2. Right click within the Package Explorer and Select “New” and in the sub-menu “Other…”
3. Then select “Plug-in from Existing Jar Archives” and follow the steps

While this is fairly straightforward, the result can be a bit too generic. For example the export of all packages and the resulting directory structure of the plug-in may not be exactly as desired. If so, the plug-in can also be created fully manually:

1. Go to the “Plug-in Development” Perspective
2. Right click within the Package Explorer and Select “New” and in the sub-menu “Plug-in Project”
3. Follow all the steps as desired, then create the desired folder structure and configuration

To now export the packages more selectively do the following:

1. Open the MANIFEST.MF file
2. Go to the tab “Runtime” and “Add…” all the jar files (ensure they are added to the build path too)
3. Selectively add the packages you like to export

Any plug-in that wishes to use the exported packages, now only has to add them under “Imported Packages”, a dependency under “Required Plug-ins” is not required.

Associating jar executables with java.exe in Windows 7

Always when I reinstall Java, it seems the association to execute jar files is lost. It is easy to restore though. Right click the cmd.exe and run it as Administrator. Then type the following:

C:\>assoc .jar=jarfile
C:\>ftype jarfile="C:\Program Files\Java\jre7\bin\java.exe" -jar "%1" %*

Instead of java.exe you may like to use javaw.exe, as it does not open a console window. But note, unless your program starts a graphical interface you have to close it via the Task Manager.

Issues with Scala Tuples

After a while of diffing through Scala code and working a bit with it, some aspects appear less comforting about how tuples are realized.

Take the following example in Python:

>>> (text1, Text2) = ("aa", "bb")
>>> text1
'aa'
>>> Text2
'bb'

Easy and simple. The same in Scala:

scala> val (text1, Text2) = ("aa", "bb")
:7: error: not found: value Text2
       val (text1, Text2) = ("aa", "bb")

Yes, from an end-users perspective the “flexible” language does not allow you to name the values in a way you want. Naming the first letter uppercase throws an error. It seems the reason is pattern matching, as described here: Link to scala-lang.org.

Another part of tuples I find less straightforward is the access to the individual tuple elements in Scala:

scala> val tup = ("aa", "bb")
tup: (String, String) = (aa,bb)
scala> tup._1
res1: String = aa

Everything else in Scala seems to start with a zero-based index. As per Martin Oderski’s book, the reason for this is because Haskell and ML have this as naming convention. From an end-user perspective, this is one more “exception” from the rule a person has to remember. Why would you make such tradeoff’s when you don’t need to? It really seems like a missed opportunity for a new language to get some consistency in place… .

Tuples and Triples in Scala

In Java, to use a Tuple or even Triple as a key for a HashMap typically requires a custom class with custom hashCode and equals calls. Scala makes this quite easy and convenient:

object Main {
    def main(args: Array[String]): Unit = {
    	// create a map with a tuple as key
        var map = HashMap[(Int, String), String]()
        
        // add
        map.put((3, "A"), "Abc");
        map.put((3, "B"), "BBc");
        
        println(map)
        println("(3, \"A\").hC() ", (3, "A").hashCode())
        println("(3, \"B\").hC() ", (3, "B").hashCode())
        println("(3, \"A\")==(3, \"A\") ", (3, "A") == (3, "A"))
        println("(3, \"A\") == (3, \"B\") ", (3, "A") == (3, "B"))
        println("(3, \"A\").eq((3, \"A\")) ", (3, "A").equals((3, "A")))
        println("(3, \"A\").eq((3, \"B\")) ", (3, "A").equals((3, "B")))
        
        // and using Triple is the same
        var map2 = HashMap[(Int, Int, String), String]()
    }
}

Scala and MultiMap – first steps

After having a few run’s with Scala, I came across the MultiMap trait. Below an example that could represent a mapping of postcodes to their starting number, e.g. 3 as a key to all postcodes with 3.

import scala.collection.mutable.Set
import scala.collection.mutable.HashMap
import scala.collection.mutable.MultiMap

object Main {
    def main(args: Array[String]): Unit = {
        // data
        val set1 = Set(1, 11, 12, 13);
        val set1b = Set(111, 1111, 112, 113)

        // standard HashMap
        // add set, add second set
        val mymap = HashMap[Int, Set[Int]]()
        mymap.put(1, set1)
        mymap(1) ++= set1b // mymap(1) needs to exist!

        println("Std map, req 1: "+mymap.get(1))

        // with multimap
        var mm = new HashMap[Int, Set[Int]] with MultiMap[Int, Int]  
        set1.foreach(mm.addBinding(1, _))
        set1b.foreach(mm.addBinding(1, _))
        // or mm(1) ++= set1b if mm(1) exists

        println("Multi map, req 1: "+mm.get(1))
    }
}

Overall, the addBinding call removes the checking of the Set that would need to be in place for future additions. Neat.

jMock and concatenated function calls

In the search for a bit more abstraction of my Java program I ran into an issue of jMock and concatenated function calls. For single objects with function calls, jMock is easy:

// objects
final Mockery context = new Mockery();
final IRectangle rec = context.mock(IRectangle.class);

// expectations
context.checking(new Expectations() {{
    exactly(1).of(rec).getBounds(); will(returnValue(new Point(1,1)));
    }});

// call and assert
Point p = rec.getBounds();
context.assertIsSatisfied();

If Rectangle becomes further abstracted and encapsulated in some higher level class that is being used instead of the low level class, the same call will create a chain of calls to get the same object:

Point p = shape.getArea().getRectangle().getBounds();

The resulting expectation is NOT:

context.checking(new Expectations() {{
    exactly(1).of(shape.getArea().getRectangle()).getBounds(); will(returnValue(new Point(1,1)));
    }});

But there is a quite simple solution. Create each abstraction layer individually and add valid expectations to allow it proceeding to the next layer:

final Mockery context = new Mockery();
final IShape shape = context.mock(IShape.class);
final IArea area = context.mock(IArea.class);
final IRectangle rec = context.mock(IRectangle.class);

// expectations
context.checking(new Expectations() {{
    allowing(shape).getArea(); will(returnValue(area));
    allowing(area).getRectangle(); will(returnValue(rec));
    exactly(1).of(rec).getBounds(); will(returnValue(new Point(1,1)));
    }});

// call and assert
Point p = shape.getArea().getRectangle().getBounds();
context.assertIsSatisfied();

Edit: The comment from Steve below is a very helpful hint in this matter!