John Developer

Netbeans 6.5 ships with Developer Collaboration as default. It may not be obvious from the description or from the dialogs, but it seems the feature works with any normal Jabber account. So there's no need to create yet another account on share.java.net, but you can use an existing account on a public or in-house Jabber server. We have tried it with two accounts on jabber.ccc.de and were able to use the Collaboration successfully.

There is a major drawback, though: Collaboration doesn’t implement the concept of Jabber Resources. You can’t set the resource to use in Netbeans or it’s priority. That means that messages that others send to you end up in Netbeans as new collaboration session. In the contact list you can’t select the resource of other people, either. Essentially that means that you can’t use your normal chat account for Collaboration.

The directory stack of Unix shells is a useful feature to set temporary “bookmarks” to directories, but I find pushd and popd long and cumbersome to type. I can recommend to alias them to ‘+’ and ‘-’, which are easy to remember and fast to type:

alias +='pushd .'
alias -- -='popd'

Konsole, the terminal emulator of KDE, is scriptable via DCOP (the IPC mechanism of KDE3). I use this feature to start a Konsole session with several tabs. Each tab has its title set to a meaningful name and possibly a command executed. I use this when running an application in JBoss. In the first tab JBoss is run, in the next I let the JBoss log scroll through, in the next I watch the application log, and so on. You may find your own usage for tasks you do daily.

One “trick” is to start Konsole with the --script option. Only then (for security reasons) will it let you send commands via DCOP that are executed in the shell.

This is the shell script I use:

#!/bin/sh

function createSession() {
        dcop=$1; shift
        title=$1; shift
        session=$($dcop konsole newSession)
        sleep 0.2 # ugly, but necessary
        $dcop $session renameSession "$title"
        for each in "$@"; do
                $dcop $session sendSession "$each"
        done
}

JBOSS=/opt/jboss
LOG=$JBOSS/server/default/log
konsole --script &
pid=$!
sleep 1
dcop="dcop konsole-$pid"
$dcop "konsole-mainwindow#1" maximize
session=$($dcop konsole currentSession)
$dcop $session renameSession "jboss-run"
$dcop $session sendSession "cd $JBOSS/bin"
createSession "$dcop" "jboss-log" "cd $LOG" "less server.log" "F"
createSession "$dcop" "app-log" "cd $LOG" "less application.log" "F"
createSession "$dcop" "tmp" "cd /tmp"

If you need more tabs add more createSession lines. You can add a variable number of commands that are to be executed in the tab. As you can see with the less command, you can also send simple keystrokes to the started programs.

When editing source code in Vim I want to have a soft limit on 80 columns. I try to generally format code to fit this convention, but with the possibility to escape it if it gets too ugly. That's why I wouldn't :set textwidth=80. Instead set an additional syntax highlighting rule, by adding to your .vimrc:

" Highlight column 80
match CursorColumn /\%80v./

This adds to an existing syntax highlighting, so you can keep your existing highlighting or file type settings as they are.

See :help \%v for an explanation. See also Vim Tip #810 or #1523.

When you thought about creating a global keyboard shortcut to restart your development JBoss, then software quality is not good enough!

Ever dreamed of container managed persistence for your PostGIS database? Here's one solution.

PostGIS is a spatial extension to the PostgreSQL database which adds support for geographic objects and operations. Because of these new database types special treatment is needed when defining your persistent unit and generating your entity beans.

First of all you have to download the hibernate spatial extension libraries hibernate-spatial-1.0-M1.jar and hibernate-spatial-postgis-1.0-M1.jar from http://www.hibernatespatial.org. Additionally the Java Transaction Service library jts-1.8.jar (http://www.vividsolutions.com) is needed. Put all these JAR-files to your JBoss lib folder.

When defining your persistence unit your have to register the new hibernate dialect org.hibernatespatial.postgis.PostgisDialect, e.g.:

<?xml version="1.0" encoding="UTF-8"?>
<persistence
        version="1.0"
        xmlns="http://java.sun.com/xml/ns/persistence"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
                http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd ">
    <persistence-unit name="SpacialDatabasePU" transaction-type="JTA">
        <jta-data-source>java:/SpatialDatabaseJNDIName</jta-data-source>                                                                                                                                                                                                              
        <properties>
            <property name="hibernate.dialect"
                    value="org.hibernatespatial.postgis.PostgisDialect"/>
        </properties>
    </persistence-unit>
</persistence>

After generating your entity beans you will recognize that all of the non-standard database types are mapped to Object and are annotated with @Lob. Replace the Object type by the actual needed spatial type, e.g. com.vividsolutions.jts.geom.Geometry, and annote them with their hibernate spatial pendant, e.g. @Type(type = "org.hibernatespatial.postgis.PGGeometryUserType"). Don't forgett to modify getters and setters accordingly.

Have you tried turning it off and on again? If you make changes to a data source descriptor (a *-ds.xml file), after deployment restart JBoss to put them into effect! JBoss will log that it has successfully deployed the file, but not actually adopt the changes. The first database operation will fail and very misleading error messages follow.

(This may be well be a problem on my side. Any hints?)

Ever needed to bridge an Ethernet connection over a couple of miles?

FreeWave Technologies Inc. sales some 900 MHz wireless data transceivers which are specified to work in a distance of up to 40 miles with a clear line of sight.

By following the installation guide, you only need to perform some basic configuration (IP address, radio channels, encryption ...), attach an antenna, connect a computer each site - and everything should work.

Three month ago, one of my new HTplus/HT devices just did not accept its IP configuration made via the serial port setup connection. No matter which IP had been set up, the box did not answer to HTTP request to its web front end over Ethernet.

After some useless calls of the FreeWave support I took a look at their firmware image which is provided for updating from older firmware releases. (You will find it in the customer support section of their homepage. Just ask FreeWave for a login.)

The firmware contains all partitions for the radio transceiver. To access the root partition, simply rename the file to firmware.gz and gunzip it. Afterwards, use your favored editor to open the file. Search for "-rom1" and remove everything before this text.

Now you can mount romfs image by mount -t romfs -o loop firmware /mnt

Now, apart from finding a BusyBox Linux in your local /mnt, it has been discovered that the serial configuration interface of the HTplus is performed through the program bin/fwSETUP. In this program you could see some interesting lines:

Enter Password: ^@J0rdan,Fu3rst1!^@r^@/mnt/webpassword^@

HELLO MASTER JORDAN^M
^@^M
1) Enter Radio Setup^@^M
2) Switch Images^@^M
3) System Console^@^M
Esc) Exit^@^M

First, this leads to the correct assumption, that a guy (probably Jordan) implemented the secret master password "J0rdan,Fu3rst1!". Second, there seems to be a hidden setup menu which offers a terminal to the Linux system (key 'B' by manual trying).

Finally, the reason for the HTplus device to not properly configuring its Ethernet interface was caused by a broken config.xml somewhere in /var. By copying the default file from /etc/config.xml to this location the problem was solved.

Unfortunately, FreeWave removed the master password and the hidden setup menu in firmware version 2.11. Now you have either to get an older firmware or you have to patch the most recent one in order to get access to the running Linux system.

Note to self: Contact FreeWave asking for the source code since BusyBox is GPL.

Starting with EJB 3.0 you can write Message Driven Beans using Java 1.5 annotations without having to write an XML deployment descriptor file, e.g.:

@MessageDriven(activationConfig =  {
        @ActivationConfigProperty(propertyName = "destinationType",
            propertyValue = "javax.jms.Topic"),
        @ActivationConfigProperty(propertyName = "destination",
            propertyValue = "JMS/Topic"),
        @ActivationConfigProperty(propertyName = "messageSelector",
            propertyValue = "example = 'TestValue'"),
        @ActivationConfigProperty(propertyName = "acknowledgeMode",
            propertyValue = "Auto-acknowledge"),
        @ActivationConfigProperty(propertyName = "subscriptionDurability",
            propertyValue = "Durable"),
        @ActivationConfigProperty(propertyName = "clientId",
            propertyValue = "ExampleBean"),
        @ActivationConfigProperty(propertyName = "subscriptionName",
            propertyValue = "ExampleBean")
    })
public class ExampleBean implements MessageListener {
    // ...
}

You can create several instances of the same Bean class, e.g. to have several instances for different message selectors or to listen on more than one Topic. To achieve this, move the properties out of the annotations and put them into an XML deployment descriptor.

The class file reduces to:

    @MessageDriven
    public class ExampleBean implements MessageListener {
        // ...
    }

Now create a file ejb-jar.xml (“New ► Standard Deployment Descriptor” in Netbeans). It has to end up in the META-INF/ directory in the deployment .jar file (Netbeans automatically creates ant rules for this).

The outer frame is:

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar xmlns = "http://java.sun.com/xml/ns/javaee"
         version = "3.0"
         xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation = "http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">;
    <enterprise-beans>
    </enterprise-beans>
</ejb-jar>

Inside the <enterprise-beans> tag, for each Bean instance create one <message-driven> section:

<message-driven>
    <ejb-name>AnotherExampleBean</ejb-name>
    <ejb-class>package.path.to.ExampleBean</ejb-class>
    <transaction-type>Container</transaction-type>
    <activation-config>
        
    </activation-config>
</message-driven>

Gotcha

You can choose the <ejb-name> for the instances freely, but one of the instances must be called exactly like the Bean class (ExampleBean in the example).

Inside <activation-config>, for each of the properties in the annotations above (destinationType etc.) create an <activation-config-property>:

<activation-config-property>
    <activation-config-property-name>destinationType</activation-config-property-name>
    <activation-config-property-value>JMS/Topic</activation-config-property-value>
</activation-config-property>

Enterprise Java Beans 3 (EJB3) cut back on the extensive use of a XML deployment descriptor. One useful application of such a descriptor is to “inject” values from this configuration file into member variables of a Bean object at deployment time.

Inside the bean use the @Resource annotation on the declaration of the variable you want to set:


@Resource(name="ExampleValue")
public String exampleValue = null;


Then in the deployment descriptor, inside the section of the Bean, create an <env-entry>:

<env-entry>
    <env-entry-name>ExampleValue</env-entry-name>
    <env-entry-type>java.lang.String</env-entry-type>
    <env-entry-value>Test</env-entry-value>
    <injection-target>
        <injection-target-class>package.path.to.ExampleBean</injection-target-class>
        <injection-target-name>ExampleValue</injection-target-name>
    </injection-target>
</env-entry>

For the <env-entry-type> you can choose one of the java.lang. wrappers around Java’s primitive types or java.lang.String.

Note that the container injects the value after object construction, so it is not yet available in the constructor.

If the resource is not configured or the names mismatch, a warning will be logged, but the Bean will start anyway. So check that the value is set programmatically, too.