Book - Configuring IPCop Firewalls

IPCop is a powerful, open source, Linux based firewall distribution for primarily Small Office Or Home (SOHO) networks, although it can be used in larger networks. It provides most of the features that you would expect a modern firewall to have, and what is most important is that it sets this all up for you in a highly automated and simplified way.

This book is an easy introduction to this popular application.
Read more »

Quickly Determining the Key From a Key Signature

A couple of days ago a friend of mine asked me how you can determine the key of a music score by observing its "key signature". The key signature is the set of ♯ or ♭ symbols that are placed on the staff to indicate the notes that should be played one semitone higher (in the case of ♯) or lower (in the case of ♭) along the score (unless an accidental indicates otherwise). An example key signature (A major or F♯ minor) is shown below:

The key signature, despite its name, is a tool meant to reduce the number of accidentals in a score but it might not necessarily match the key of the score. Nevertheless, most of the time, it will.


The notational convention used comes from the circle of fifths:

Basically, the circle can be navigated clockwise or counter-clockwise, starting from the upper C, down to the G♭/F♯. In every "step" a symbol is added to the key signature: a ♯ if the circle is navigated clockwise or a ♭ if the circle is navigated counter-clockwise. The rule to add the symbol to the key signature is the following:

• A ♯ shall be added to the leading note for the major scale or, equivalently, to the supertonic for a minor scale.
• A ♭ shall be added to the subdominant for the major scale or, equivalently, to the submediant for a minor scale.

So far, so good, but theory would not help my friend so much, would it?

Fortunately, there's a quick mnemonic to find out the key from a key signature.

• In the case of a key signature made up of ♯ symbols: Since, as explained earlier, the new ♯ shall be placed on the leading note (in the case of a major scale), the mnemonic is: look at the last ♯ in the signature and raise it by one semitone. That's the corresponding major key.
• In the case of a key signature made up of ♭ symbols: Since the new ♭ shall be placed on the subdominant (in the case of a major scale), take the second last ♭: that's the corresponding major key. If the signature has got only one ♭, that's a F major (that's easy).

For example, if we look at the following signature:

The last ♯ symbol is a E♯. If we raise it one semitone we've got a F but, since the F is already marked as F♯ on the signature, the corresponding major key will be F♯.

If we look at this signature:

The second last ♭ is a C♭: the corresponding major key is, indeed, C♭.

Jolicloud Renames Itself 'Joli OS'

Jolicloud is an internet based operating system similar to Google Chrome OS. The company (by the same name) also markets a laptop (Netbook) called Jolibook which runs Jolicloud OS.

Read more »

GNOME 3 Won't Have Minimize And Maximize Buttons

GNOME 3 is doing away with minimize and Maximize buttons for applications in its user interface. The basic premise being they don't make sense within the current shell design.

Of course, that doesn't mean you can't minimize or maximize your applications' window in GNOME 3.
Read more »

MeeGo - A Compendium Of Facts

This is a concise guide that provides some details about a possible Android and IOS contender - MeeGo. Notwithstanding the recent setbacks it faced in relation to Nokia, MeeGo project is moving forward at a steady pace. And it might just be possible that we could,in the near future, start seeing increasing number of devices (not just cell phones) powered by MeeGo.

MeeGo is an open source operating system project for mobile devices, hosted by the Linux Foundation - a non-profit consortium dedicated to fostering the growth of Linux.
Read more »

Upgrading Oracle Glassfish Server to v. 3.1

Oracle Corporation just released Oracle Glassfish Server v. 3.1: this release includes many interesting features and I started upgrading as soon as I could allocate some time. The official Glassfish Server 3.1 Upgrade Guide can be found here.

In a very recent post, I described how you can upgrade your Glassfish instance to v. 3.0.1 using the tools provided by the application server. With the release of version 3.1 things haven't changed so much so that, if you're in a hurry, you can just follow those instructions.

Nevertheless, I'll take advantage of this news to summarize which are the possible upgrade paths for your Glassfish instances so that you can choose the one that best fits your needs:

• Upgrade tool.
• Update tool.
• pkg tool.
• Software Update Notifier.

Upgrade Tool

The upgrade tool let us perform side-by-side upgrades and it's the only tool that can be used to upgrade a Glassfish instance earlier than Glassfish v. 3.0.1 or Enterprise Server v. 3.0.

The ability to perform side-by-side upgrades is important in the cases in which you do not want to upgrade your existing installation. In the case something goes wrong during the upgrade procedure, the original instance is not modified and the administrator is free to try the upgrade procedure again or restart the old instance until further investigation is done.

The upgrade tool, installed on $GF_INST/glassfish/bin/asupgrade, can be used both in graphical or command line mode. To use this tool, both the source and the target server directories must be accessible from the system in which asupgrade is launched and the user must have read permission on the source and read and write permission on the target directory.

Before launching the tool, the Glassfish domain to be upgraded must be stopped. Also, the official documentation suggests to manually copy libraries in the server /lib directory from the source to the target server. As pointed out in Bobby's comment, older versions of this tool (such as v. 3.0.1) even tried to detect and copy user libraries from $GF_INST/glassfish/lib: the upgrade tool bundled with GlassFish 3.1 will not so that it's important to manually check this directory to manually migrate libraries form one server installation to another.

The options accepted by the tool are the following:

• -c|--console: Launches the tool in command-line mode.
• -V|--version: Dumps the tool's version number.
• -h|--help: Dumps the tool's arguments' help.
• -s|--source: Specifies the source domain directory.
• -t|--target: Specifies the target domain root-directory.
• -f|--passwordfile: Specifies a password file with Glassfish master password.

The quickest way to launch the tool is just:

asupgrade

to launch it in GUI mode, or

asupgrade -c

if you prefer using the CLI mode. In either mode, just supply the required parameters and proceed with the upgrade information.

If you need to automate the upgrade procedures of multiple domains, perhaps you'd rather use the asupgrade tool in a script:

asupgrade -c \

  -s /path/to/source/domain \

  -t /path/to/target/root/domain

At the end of the upgrade procedure, you should check the logs to verify that no error was encountered during the process. If everything is ok, you can now start your new Glassfish v. 3.1 domain.

Update Tool and pkg Tool

The update tool and the pkg tool are, respectively, a GUI and a CLI utility, which are part of the Update Center Tools. Although very similar, they do not provide the same set of features to the user. Nevertheless, as far as it concerns the upgrade procedure, they can be used interchangeably and whether you want to use one or the other is just a matter of taste and opportunity.

The biggest differences with the upgrade tool describe in the previous section is that these tools cannot be used to upgrade instances earlier than 3.0.1 and they do modify the server installation directory during the upgrade procedure. Should the procedure fail, although both the tools and the upgrade procedure are very resilient, the administrator could be left with a non-functional Glassfish installation. The biggest advantage is that it's a very quick upgrade path.

Before upgrading, as usual, Glassfish domains should be stopped.

To update tool can be launched with the:

$GF_INST/glassfish/bin/updatetool

command and its GUI will appear. On the main window, click the Available Updates control, select all items on the list and proceed with the upgrade procedure. The server will be upgraded to version 3.1 and, at the end of the procedure, the existing domains must be upgraded starting them with the --upgrade options:

asadmin start-domain your-domain --upgrade

Despite the name of the command, at the end of the upgrade the domain will be stopped. After upgrading all of your domains, you can start them normally.

Upgrading using the pkg command will be familiar to long time (Open)Solaris users. Glassfish bundles a version of the pkg command to support IPS repositories. To upgrade Glassfish to the latest version is sufficient to launch the following command:

$GF_INST/glassfish/bin/pkg image-update

After the upgrade completes correctly, each Glassfish domain should also be upgraded as explained in the update tool case.

Software Update Notifier

The Software Update Notifier is yet another Update Center tool and, as such, it enables the administrator to perform upgrades under the same conditions explained in the previous section.

The Software Update Notifier, if installed, periodically checks if updates are available and, when they are, it suggests the administrator to install them with a fancy notification balloon. When all domains are stopped, the upgrade process can be started accepting the notification in the balloon.

After the upgrade completes correctly, each Glassfish domain should also be upgraded as explained in the update tool case.

Do not return in a finally block: return will swallow your exceptions

This is a blog post that should not be. Unfortunately, this is a recurring mistake I'm seeing out there and hope this can help people prevent it.

Yesterday I've been busy troubleshooting a problem we were experiencing in a cluster of application servers. We narrowed down the problem to a module implementing the JAAS login protocol and, according to the failing module documentation, we should have received a LoginException generating from an UnsupportedOperationException launched down the call stack. Instead, the module was silently failing and returning a reference to a partially constructed JAAS Subject.

We checked out the module source code and it took us few minutes to detect the problem. The module was correctly implementing its documented protocol and was generating the UnsupportedOperationException as expected. The author, unfortunately, forgot one of the rules of the Java Language and was returning from a finally block, effectively discarding the exception that was launched just a couple of lines before.

That's amazing how many times I see people returning from a finally block without understanding what the code is intended to do.

Still not convinced?

Run this:

@Test
public void hello() {
    try {
        throw new UnsupportedOperationException();
    } finally {
        return;
    }
}

No exception is thrown. Surprised? You should not. There are plenty of variations of this theme out there. Nevertheless, if you're still surprised that the hello() method completes without throwing an UnsupportedOperationException, please read on.

try/catch/finally blocks

According to the Java Language Specification, this is a simplified vision of what happens during the execution of a finally block (you can read the normative documentation here):

• If the finally block completes normally, then the try statement completes abruptly for reason R.
• If the finally block complete abruptly for reason S, then the try statement completes abruptly for reason S.

As you may notice in the JLS, then, the "reason" a try statement completes with will always be affected by an abrupt completion of a finally block. Said in other words, the finally block will "decide" what happens later.

You probably though many times about what happens if an exception is thrown in a finally block, don't you? Perhaps you even tested that case: the exception that will be propagated up the stack will be the exception launched in the finally block. That's not surprising, after all, and that's why you should carefully check that the code in finally blocks don't fail without control.

So far, so good. But what happens, then, when a return statement is executed inside a finally block?

The return statement

What Java programmers often misunderstand is the very nature of a return statement. The Java Language Specification is clear about that:

The return statement always completes abruptly.

That's why exceptions launched in try or catch blocks (the "reason" of their abrupt completion) are simply ignored and not relaunched when a finally block completes abruptly with a return statement, being that the "resulting" reason of the abrupt completion of the try statement, as seen in the previous section.

Lesson learned

I personally don't see any good reason, unless you want any exception to be swallowed, to return in a finally block: it defies the very reason for try/catch blocks to exist.

Do think twice (or more...) before using this construct: chances are you're doing a favor to others and yourself if you avoid it.