Change LogFormat of a Server-App site in Mavericks

The server application of OSX Mavericks is using instead of
the configuration at the location
Anyways, if changing the CustomLog behaviour there, there will be no effect, as for each site a separate virtual host config is created, located in the subfolder sites in which the change has to be applied.
After an apache restart, one should see the changes.
There are four predefined log formats available:

  • combined: “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\””,
  • combinedvhost: “%v %h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\””,
  • common: “%h %l %u %t \”%r\” %>s %b”,
  • commonvhost: “%v %h %l %u %t \”%r\” %>s %b”.

AndroMouse fix for Mountain Lion

I recently found this Android app “AndroMouse“. As I am using Mountain Lion, i ran right into problems when i tried starting their Server application.
I figured it had something to do with BlueCove, which is part of the Bluetooth-Framework of Mac.
As it turned out, I was right and Apple removed some deprecated code of the Framework in their new OS Version “Mountain Lion”.
To fix this, one could attempt to replace the new version of the framework with the old version of the framework, at least the parts needed (IOBluetooth, that is).
But this would be an evil hack.
So instead, one could feed the application to be started (in this case, Andro Server) with the path of the old IOBluetooth.
The easiest way to do this, is to write a small shell script:

export DYLD_LIBRARY_PATH=$(cd "$( dirname "$0" )" && pwd)
open -F ~/Desktop/AndroMouseServer.jar

The path to open is of course to be alternated to the path actually needed.
In addition, one needs to copy the old IOBluetooth (unzipped!) to the directory in which the shell script is executed.

Cookscrap for a JNLP with JNI components

Writing a JNLP with native components is fairly easy.
First of all you have to know that each JNLP uses (per default) sandboxing. Which means that no external resouces that you’d normally access via “System.load( … )” are available. There indeed are options to disable this sandboxing, but I personally do not think that this is as intended by the inventor.
Anyhow there is the possibility to hand in native libraries.
To reach that goal, all you need to do is wrap all your native components into single JAR (which is now platform dependant, so you’ll probably need more than just one jar), sign it and reference it in your JNLP. This is done by the tag <nativelib href=”lib/windows/corelib.jar”/>.

Usually you’d like to wrap this in a resource element specifying the needed environment. Just like:

    <resources os="Windows">
        <nativelib href="corelibs.jar"/>

Now what happens under the hood? Instead of using java.lang.path (which is equal to PATH in windows or equal mechanisms under different operating systems), it’ll create a folder in the application cache which is also made accessible. Like that you can naturally use all your native libs just like you are used to (if you are used to it at all) ;).

GWT serialization and cell widgets

Lately I’ve been busy with writing some GWT-app based on a content management system. In order to display data, it would be best to use Cell-Widgets. If content gets changed in the browser, somewhere a button-widget is added and one can update it with some RPC call. So far so good. Let’s look at this small sample:

public class Contact implements IsSerializable{
	private String	name;
	public Contact(){} // default constructor for serialization
	public Contact(String name){ = name;

As our data objects and somewhere else in the client code:

CellList<Contact> cellList = new CellList<Contact>(new AbstractCell<Contact>() {
	public void render(Cell.Context context, Contact value, SafeHtmlBuilder sb){
		sb.appendHtmlConstant("<b>" + + "</b>");

Now our cellList gets populated with data, no matter in which kind (either directly, or with some kind of data provider).
If we want to gather our data back out of the cell widget, we usually call:

List<Contact> ourData = cellList.getVisibleItems();

No problem yet. But now the data is useless as long as it stays in the client. We need to get it back to the server. How do we do that? Correct: RPC.
This is where the problems begin – if we execute the call it will fail with a serialization exception.

How could this happen? We did everything correctly: Contact implements IsSerializable (the marker interface for gwt-serialization), it even has the required default constructor. So this can’t be the problem.
If we have a closer look, we see that cellList returns a list of contacts (of course it does, since it contains more than one contact.. deuh). Lists are serializable, usually. LinkedList, ArrayList – everything we could guess of.
But internally, CellWidgets return their data via

public List<T> getRowDataValues() {
      return Collections.unmodifiableList(rowData);

which is NOT serializable. So this is where we have to look for a solution.
My simple approach that actually works: Wrap the returned list into a new (serializable) list, which will cause the internal data-structure to be overwritten. Sample:

List<Contact> ourData = new LinkedList<Contact>(cellList.getVisibleItems());

In a nutshell: Never send the data of cell widgets back to the server directly, as the internally used structures are not serializable.