One of the things I have been running on my VM is a TCP-over-DNS server; it will allow you access to the Internet through some access points where you’re forced to login, though it relies on the network administrator neglecting to block certain types of DNS query.  The author has posted a good how-to and overview of how it works so I’m not going to go into that here.

Now, I don’t anticipate using this tunneller very often so it’d be nice to not run the daemon all the time, but I obviously can’t enable myself unless I know in advance that I won’t have Internet access. Therefore, ideally I want the server to run only when I want to use it. Fortunately Linux has long had a means of doing this with the inetd daemon.

The inetd daemon will monitor a network socket, waiting for incoming traffic, and launch your daemon only when it is needed. It then passes the daemon process the existing sockets and waits for it to finish, at which point it’ll go back to watching for traffic again.

The config line you’ll need for inetd is as follows (you may need to highlight it and copy it elsewhere, as it doesn’t show up well in this theme):

domain  dgram   udp     wait    root    /usr/bin/java   java -jar /path/to/tcp-over-dns-server.jar --domain delegated.domain.com --forward-port 22 --forward-address 127.0.0.1 --mtu 1500 --log-level 1 --idle-timeout 10 --log-file /var/log/tcp-over-dns

Aside from modifying the server to support inherited channels I have:

1. Added an idle time limit (so the program can exit if it sees no clients after a set number of seconds, and let inetd monitor the port again)
2. Added a log file option (programs launched by inetd can’t log to the standard output or error channels as inetd will pipe them into the inherited connection.)
3. Changed the default behaviour (If a channel is inherited the server will no longer try to bind on its default port)

If you’re interested you can download the source code or just the pre-compiled jar file.

The first project ran afoul of bug #6669818 which prevented the applet from connecting back to the originating server during LiveConnect calls, in Mozilla Firefox on a Windows XP platform.

Fortunately there is a workaround for this; by passing the task off to another thread which was started in a non-LiveConnect part of the Applet’s lifecycle, the task is then executed in another thread which is not subject to the same malfunctioning security check.

If you’d rather not have to create a thread just for this, a quick hack is to pass the event off to the applet rendering thread using the SwingUtilities.invokeLater(Runnable); function.

In the second project I’ve now encountered another platform-specific Applet quirk, this time with Mac OSX.

Using Javascript it is possible to change the size of an Applet on the page in the same way you would any other DOM element, however on Mac OSX any browser using the Java Embedding Plugin (Firefox, Opera and others) will fail to resize Java Applets correctly.

I’ve knocked up a simple test page which allows this to be tested, and shows a potential workaround.

There appear to be two problems cropping up; the first is that the Browser does not notify the Applet that it ought to resize. If you leave the “Notify Java” check-box un-checked when submitting the form, the browser expands the area the Applet ought to be using, but the applet continues to draw in it’s original position.

The second issue is that when axis are changed and Java is manually notified the behaviour still does not perform as it ought to. The clipping region of the Java applet rendering is not updated correctly, and thus only part of the applet is correctly rendered.

There is a temperamental workaround for this, by programatically resizing one axis and then the other in quick succession, but this seems to fail as often as it works, depending on whether the page is being loaded from nothing, refreshed, no-cache refreshed or returned to via the browser ‘Back’ action.

In the interest of getting this bug fixed the code to the Applet resize test page is linked from the test page and free for all to use.

Bugs:

• Java Embedding Plugin tracker: #2030298
• Firefox Bugzilla: #451882

As part of this I was trying to make a multi-page form, using Spring‘s AbstractWizardFormController and spent an hour or so trying to make the form submission change the form page. My problem was that it wasn’t immediately obvious how to use the form taglib with the Wizard architecture.

The docs mentioned using request parameters, which was a bit confusing as I was using a POST form submission, however all you actually need to do is add one of these parameters to the form data (usually using a button).

Finish and cancel actions can be triggered by request parameters, named PARAM_FINISH (“_finish”) and PARAM_CANCEL (“_cancel”), ignoring parameter values to allow for HTML buttons. The target page for page changes can be specified by PARAM_TARGET, appending the page number to the parameter name (e.g. “_target1″). The action parameters are recognized when triggered by image buttons too (via “_finish.x”, “_abort.x”, or “_target1.x”).

For example:

<input value="Submit" name="_target1" type="submit"/>

This will request to change to page 2 of the form (remember Array base is 0).
Because of the way forms work, you can have a number of these (either as clickable images or buttons) and only the one the user eventually selects will be submitted with the request.