javax.net.ssl.SSLPeerUnverifiedException after installation of a new JDK on MacOSX

• After installing the new JDK (1.6.0_26) as normal user having the authentication dialog pop up for my admin account. I had loads of problems with javax.net.ssl.SSLPeerUnverifiedException popping up.
• I even was not able to start the /Applications/Utilities/Java\ Preferences.app/ and got a strange error.
• Logging in as admin did not help either, I still was not able to start the preference app.
• I downloaded the JDK as admin again and repeated the installation.
• I rebooted my system and now was able to open the preference app, reset to default options and the javax.net.ssl.SSLPeerUnverifiedException were gone.

Starting an Android emulator automatically on MacOSX after Login via LaunchAgent

Homebrew offers a simple means to install additional software packages on your MacOSX computer. After initial installation of brew as admin user execute:

brew install android-sdk # will install the newest SDK starter package
android update sdk # this will open the UI, now install all platforms
chgrp -R staff /usr/local/Cellar/android-sdk/r7 # otherwise the ANDROID_HOME will be owned by the wheel group and you may not start anything as non admin user.

To use tools like the emulator add ANDROID_HOME and ANDROID_SDK_ROOT to your $HOME/.profile or $HOME/.bash_profile (if the latter exists, use this):

ANDROID_SDK_ROOT=/usr/local/Cellar/android-sdk/r7
ANDROID_HOME=$ANDROID_SDK_ROOT
export ANDROID_SDK_ROOT ANDROID_HOME

Create an emulator called Wildfire using the android command. Now if you want the emulator to be started automatically after you login, put the following into $HOME/Library/LaunchAgents/emulator-wildfire.plist:

After you saved the file, execute launchctl load $HOME/Library/LaunchAgents/emulator-wildfire.plist. From now on the emulator starts whenever you (or your CI user) logs in.

Really using launchctl to restart a Hudson Mac OS X build slave connected via JNLP automatically

In my last posting I wrote commands put into $HOME/.launchd.conf would be launched automatically after a login as stated by the man page for launchtctl. However this is false! After a reboot or relogin the commands will not be picked up! Stating man 5 launchd.conf:

$HOME/.launchd.conf  Your launchd configuration file (currently unsupported).

Pulling my ear: always try and test what you write about, sorry :-(. However using the following .plist file put into
$HOME/Library/LaunchAgents/org.hudson-ci.jnlpslave.plist really starts the slave:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>KeepAlive</key>
        <true/>
        <key>Label</key>
        <string>org.hudson-ci.jnlpslave</string>
        <key>ProgramArguments</key>
        <array>
                <string>/usr/bin/java</string>
                <string>-jar</string>
                <string>/home/hudson/bin/slave.jar</string>
                <string>-jnlpUrl</string>
                <string>http://SERVER/hudson/computer/NODE/slave-agent.jnlp</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
</dict>
</plist>

Of course you have to adapt the path to your slave.jar as well as the URL to your Hudson-master.

Using launchctl to restart a Hudson Mac OS X build slave connected via JNLP automatically

$HOME/launchd.conf does not work, see my working followup on this!

In my company's build infrastructure most of the slaves are located in the same data centre as the master. So we usually just use ssh to launch the slave.jar. As we did not want to buy XServe and our operations team would not like to host such an aberration from the usual (Linux) to build the handful of jobs which are Mac OS X only, we bought a Mac-Mini, which is part of the workstation LAN, where hudson will login automatically as we need the GUI anyway for Selenium tests.

As we have very strict firewall rules, access from the server LAN into the workstation LAN is forbidden. That's why we use JNLP to start the slave. So we've usually restarted the slave manually after the connection broke down.

Enters launchctl. Instead of fiddling around with a plist file I just used launchctl submit to achieve the same. From the commandline enter the following command:

launchctl submit -l hudson-slave -- /usr/bin/java -jar /Users/hudson/slave.jar -jnlpUrl http://SERVER:PORT/hudson/computer/NODE/slave-agent.jnlp

This will start the slave and restart it automatically if the connection ever should break down. You may watch the logging statements uttered by the slave by executing
open /Applications/Utilities/Console.app. To enable this command every time your Mac OS X machine reboots, create a .launchd.conf in the hudson user's HOME like this:

cat > /User/hudson/.launchd.conf << EOF
submit -l hudson-slave -- /usr/bin/java -jar /Users/hudson/slave.jar -jnlpUrl http://SERVER:PORT/hudson/computer/NODE/slave-agent.jnlp
EOF

You must not use the javaws way (the -wait option did not work for me), as the parent process will exit after it launched the jnlp connection and launchd will try to restart it again immediately for some times.

Command-Tab - Blog Archive - How to Test RAM Under Mac OS X

After updating my Macbook from 2GBG to 4GB I ran Command-Tab - Blog Archive - How to Test RAM Under Mac OS X five times, as the the two blocks I have got first showed artifacts on the screen, now everything is running happily :-),