Selecting the locale for an user with JSTL

In another post, I introduced the basic internationalization capabilities built in JSTL. The algorithm used to choose a suitable locale for an user is a good default choice: without any effort, your web application will show up in the correct locale.

But what if you wanted to let the user choose the locale?

Well, the JSTL Specification lets you establish a locale and a scope: such as page, request, session, application. The first sketch I'd come up with would be something like creating a servlet to enforce the programmatic configuration.

Language selector servlet

This is a servlet service method prototype:

protected void processRequest(HttpServletRequest request, HttpServletResponse response)

    throws ServletException, IOException {

    final String lang = request.getParameter("lang");

    if (isSupported(lang)) {

        Config.set(request.getSession(), Config.FMT_LOCALE, lang);

    }

    request.getRequestDispatcher("/").forward(request, response);

}

The important call here is Config.set(...): you're telling JSTL to use the specified locale (as a String) and save it in the session scope. This servlet accepts the lang parameter and, if present, uses it to determine if it represents a supported locale (isSupported implementation is omitted). If it is, it uses it as described above. At the end of it all, forwards the user at the web welcome page (if any).

Refinements

The servlet described above is the first step towards a complete user customization and is just an example of how you can use the JSTL's Config class. Desirable improvements might be:

• Saving the user servlet in its profile (if the user has been authenticated) so that future sessions will automatically use the user-specified locale.
• Using a servlet filter instead of a servlet to automatically intercept the lang parameter and leave the web navigation unaffected.

Internationalization using JSTL

The Java EE 5 platform is a powerful enterprise-level server development platform which in my opinion is very productive including to develop small web modules, provided you've got a suitable Application Server or Servlet Container to run it.

As far as it concerns web development and authoring, Java EE 5 has got some great APIs such as servlet's, JSP's and JSF's. The JavaServer Pages Specification (JSR 245) includes JSTL (JavaServer Pages Standard Tag Library, JSR 052), which are JSP standard tag extensions that include internationalization features.

Creating a Resource Bundle

The first thing you ought to do when internationalizing your application is creating resource bundles. Resource bundles are Java Properties file, organized for locales, whose aim is separating string literal according to the locale they're meant for.

Let's suppose you want to use three locales in your application:

• en_US
• it_IT
• es_ES

Create for Java Properties files, one per locale and one as a fallback. The naming scheme is [bundle-name]_[locale].properties, so that you'll end up with:

bundle_en_US.properties

bundle_it_IT.properties

bundle_es_ES.properties

Some advances Java IDE, such as NetBeans, let you manage properties files with visual tools and perform basic operations, such as adding a locale or filling up the properties, with a fancy GUI.

Filling the Resource Bundles Up

Filling up properties files is pretty easy: such files contain records with this basic structure:

key=value

In this case you would translate every key value for the correct locale.

Using a Bundle from a JavaServer Page with a JSTL tag

JSTL lets you easily use resource bundles in a JSP. The first thing you've got to do is declaring that you're going to use the JSTL's fmt tag library:

<%@taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>

The next thing is telling the library which bundle you're going to use. Let's suppose you're going to use com.domain.YourBundle:

<fmt:setBundle basename="com.domain.YourBundle" />

The last thing is using the retrieved values where you need them:

<fmt:message key="your.key" />

Determining the user locale

Maybe you're wondering how JSTL determines which is the user locale. JSTL, by default, determines the user locale by examining the headers sent by the browser and applying a best match algorithm. If your preferred language settings show (in this order)

1. English
2. Spanish
3. Italian

the resulting application will show up in English. The JSTL Specification will give you further details about how to establish a default locale for a web application using JSTL.

In another post, I'll show you how I resolved the problem of locale switching for a given user in an application of ours.

Further Readings

JSTL Specification

Sun xVM VirtualBox v. 3.1.0 has been released

Sun xVM VirtualBox v. 3.1.0 has been released. This is a major update which introduces some brand-new great features such as (change log excerpt):

• Teleportation (aka live migration); migrate a live VM session from one host to another (see the manual for more information)
• VM states can now be restored from arbitrary snapshots instead of only the last one, and new snapshots can be taken from other snapshots as well ("branched snapshots"; see the manual for more information)
• 2D video acceleration for Windows guests; use the host video hardware for overlay stretching and color conversion (see the manual for more information)
• More flexible storage attachments: CD/DVD drives can be attached to an arbitrary IDE controller, and there can be more than one such drive (the manual for more information)
• The network attachment type can be changed while a VM is running
• Complete rewrite of experimental USB support for OpenSolaris hosts making use of the latest USB enhancements in Solaris Nevada 124 and higher
• Significant performance improvements for PAE and AMD64 guests (VT-x and AMD-V only; normal (non-nested) paging)
• Experimental support for EFI (Extensible Firmware Interface; see the manual for more information)
• Support for paravirtualized network adapters (virtio-net; see the manual for more information)

As far as it concerns myself, teleportation is the feature I was looking forward. Great job, guys.

Read the changelog.

Download Sun xVM VirtualBox now.

Retrieving a server public SSL key on Solaris 10 (such as GMail's)

This is a tip for you, UNIX users (with OpenSSL installed), who wish to obtain a server's public SSL key.

I'm configuring a Java EE application that needs to connect to an IMAP server using SSL on a Solaris 10 box. For that reason, I need to import the IMAP server SSL public key into my Java runtime certificates file.

Solaris 10 brings a bundled OpenSSL package which it's very easy to accomplish this task with. Just launch your favorite shell and execute the following command:

$ openssl s_client -connect destination.server:[service|port]

In my case, being an IMAP server using a non-standard port, I used:

$ openssl s_client -connect my.imap.server:999

CONNECTED(00000004)

[...snip...]

---

Server certificate

-----BEGIN CERTIFICATE-----

MIIDWzCCAsSgAwIBAgIKYgnCCAADAAAJ5DANBgkqhkiG9w0BAQUFADBGMQswCQYD

VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu

dGVybmV0IEF1dGhvcml0eTAeFw0wOTA3MTcxNzEzNDFaFw0xMDA3MTcxNzIzNDFa

MGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N

b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRcwFQYDVQQDEw5pbWFw

LmdtYWlsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA+O0vc2pslfjk

pbxnBF4iznJMrP9Qi3fHjKqA3P2RynTcbnZfGEGMKcPeXHT4IOH6XUnf+4Jw+z7I

KiMtjX8IVGo7DeXec/ZREasEZnpMGisxN7+qk7Ho6HyaglQTAFIQJP99UFJkHO9x

dGDy5d2j9senPad1BqtyaIRGkJpHizUCAwEAAaOCASwwggEoMB0GA1UdDgQWBBT0

WHOeLKf4+VNADzHzGh+AEV+6fjAfBgNVHSMEGDAWgBS/wDDr9UMRPme6npH7/Gra

42sSJDBbBgNVHR8EVDBSMFCgTqBMhkpodHRwOi8vd3d3LmdzdGF0aWMuY29tL0dv

b2dsZUludGVybmV0QXV0aG9yaXR5L0dvb2dsZUludGVybmV0QXV0aG9yaXR5LmNy

bDBmBggrBgEFBQcBAQRaMFgwVgYIKwYBBQUHMAKGSmh0dHA6Ly93d3cuZ3N0YXRp

Yy5jb20vR29vZ2xlSW50ZXJuZXRBdXRob3JpdHkvR29vZ2xlSW50ZXJuZXRBdXRo

b3JpdHkuY3J0MCEGCSsGAQQBgjcUAgQUHhIAVwBlAGIAUwBlAHIAdgBlAHIwDQYJ

KoZIhvcNAQEFBQADgYEAXLvdKJJ6ivWAi29p4pPo4cirMEYnRlpNOmPVAW4QYcSq

lEZhm4cQdyitFo9cxiwNgbBjJk8O+oiOhnueT44RXotEE7j3KnNyPRRZg0OCagGC

4G71fFA11P1L0fSd/7k52/DbZQBea3tJgkseoGL50UVvnJm+LZOovIGxoQzipJk=

-----END CERTIFICATE-----

[...snip...]

The key I need to import is the shown certificate, including the beginning and the end line.

I saved the key in a file called imap.key and I imported in my Java runtime certificates file with the following command:

$ /usr/jdk/latest/bin/keytool -import -alias imap.gmail.com -keystore /usr/jdk/latest/jre/lib/security/cacerts -file imap.key

[Insert password here]

[Confirm key import]

Done!

Now, my Java application can use that public key to establish a secure SSL connection with the target imap host.

Protecting workflow transitions in JIRA

Today I created a bunch of new projects in our JIRA 4.0 instance and, for the first time, I needed to create a custom workflow for some issue types. JIRA is flexible and powerful and it was pretty easy to create a new workflow just cloning (copying) the default JIRA workflow. All I had to do to fulfill my requirements was:

• Define a new status: Waiting for feedback
• Define a new step: Waiting for feedback
• Create new transitions to and from this new workflow state.

Leveraging JIRA's powerful administration console the new workflow was defined in just a few minutes. Once done, I defined a new workflow scheme and associated to some of my new projects.

It was with some surprise that I realized that the new transition wasn't restricted to developers: it was there for everyone to trigger. Obviously, I'd overlooked something in the configuration so that I checked the permissions and everything seemed to be fine until I realized what was wrong: workflow transitions are protected by conditions. In my case, I required that only the issue assignee could trigger a transition.

Although the workflow was being used, creating a draft workflow was a no brainer. In the draft workflow I added the required condition:

Only the assignee of the issue can execute this transition.

Once done, I published the new workflow. JIRA quickly converted the existing issue to the new workflow and the error was corrected without even bringing the project down.

Configuring Sendmail to Relay Messages from Other Servers

Index

Part 1. Configuring Sendmail on Solaris 10
Part 2. Configuring Sendmail to Masquerade Your Messages
Part 3. Configuring Sendmail to Relay Messages to Another Server
Part 4. Configuring Sendmail to Relay Messages from Other Servers

Introduction

In the previous post you've learnt how to configure Sendmail to relay messages to another server. Now, such a server should be probably be configured to accept incoming messages to relay from other servers. Solaris 10 Sendmail default configuration does not allow message relay and proper configuration must be applied to Sendmail.

Configuring Relay for Hosts and Domains

The quickest way to have Sendmail relay messages for other domains is by modifying the /etc/mail/relay-domains file. Sendmail will relay mail for every domain listed in that file. If you want your server to relay messages for domain a.com, b.com and c.com, just insert the corresponding lines into /etc/mail/relay-domains and restart your Senmail instance:

# cat /etc/mail/relay-domains
a.com
b.com
c.com

Configuring the Access Database

If you want to relay messages from specific hosts (as well as domains and networks) you can use the access database. The access database lists email addresses, network numbers and domain names and a rule. Available rules are:

• OK: Accept mail even if other rules in the running ruleset would reject it.
• RELAY: Accept mail addressed to the indicated domain or received from the indicated
  domain for relaying.
• REJECT: Reject the sender or recipient with a general purpose message.
• DISCARD: Discard the message completely using the $#discard mailer.
• (A RFC-821 compliant error text): Return the error message.

If you want your Sendmail to relay mails for a domain or from some specific hosts, modify your /etc/mail/access accordingly:
your-domain       RELAY
192.168.0         RELAY
another-domain    RELAY
unwanted-host     REJECT

Once done, you have to generate the access db with the following command:

# makemap hash /etc/mail/access.db < /etc/mail/access

Enabling the Access Database

To have your Sendmail use the access database, you must properly configure it adding the access_db feature to its configuration file:

# cat your-file.mc
[...snip...]
FEATURE(`access_db')
[...snip...]

Restart your Sendmail and enjoy!

A Word of Warning: DNS Configuration

Sendmail often requires that host name you use in your configuration files (such as the access database) are properly configured in your name server, both for lookup and reverse lookup. I hope this will spare you some headache while debugging.

Configuring Sendmail to Relay Messages to Another Server

Index

Part 1. Configuring Sendmail on Solaris 10
Part 2. Configuring Sendmail to Masquerade Your Messages
Part 3. Configuring Sendmail to Relay Messages to Another Server
Part 4. Configuring Sendmail to Relay Messages from Other Servers

Introduction

Sometimes you just need to configure your Sendmail to relay messages to another server. I often use such a configuration to centralize Sendmail configuration: if something had to change I would just need to change a reduced number of configuration files. For example, I made heavy use of Solaris Zones technology. Unless particular configuration is needed, whenever I create a new zone, I just configure its Sendmail to relay messages to another server (which is, incidentally, one of the preconfigured Sendmail zones we use).

Setting Up a Sendmail Smart Host

Setting up Sendmail to relay messages to another server is pretty easy. Modify your configuration file and use the following macro:

[...snip...]
define(`SMART_HOST', `your-smart-host')
[...snip...]

The smart host is the host this instance will relay messages to. This macro will be translated into a DS statement in your Sendmail configuration file. You should never modify .cf files directly: always compile .mc files! By the way, sometimes is useful to know .cf syntax if you need to interpret existing .cf files when you've lost the corresponding .mc files (something that should never pass to a seasoned System Administrator).

Configuring Sendmail to Masquerade Your Messages

Index

Part 1. Configuring Sendmail on Solaris 10
Part 2. Configuring Sendmail to Masquerade Your Messages
Part 3. Configuring Sendmail to Relay Messages to Another Server
Part 4. Configuring Sendmail to Relay Messages from Other Servers

Sendmail Masquerading

Now that you've got your Sendmail up and
running it's time to do some tweaking. If you try and send mail from
your host, you'll notice that messages are sent from an address such as
your-user-name@hostname.your.domain. That's not probably what you want
(that address isn't probably even reachable from the outside) and you'd
rather like: your-user-name@your.domain. Fine, that feature is called masquerading. To masquerade outgoing mail you can use the MASQUERADE_AS and MASQUERADE_DOMAIN macros, as in the following example:

divert(0)dnl
VERSIONID(`@(#)sendmail.mc      1.11 (Sun) 06/21/04')
OSTYPE(`solaris8')dnl
DOMAIN(`solaris-generic')dnl
define(`confFALLBACK_SMARTHOST', `mailhost$?m.$m$.')dnl
MASQUERADE_AS(`your-domain.com')dnl
FEATURE(`masquerade_envelope')dnl
FEATURE(`masquerade_entire_domain')dnl
FEATURE(`always_add_domain')dnl
MASQUERADE_DOMAIN(`your-domain.com')dnl
MAILER(`local')dnl
MAILER(`smtp')dnl

LOCAL_NET_CONFIG
R$* < @ $* .$m. > $*    $#esmtp $@ $2.$m $: $1 < @ $2.$m. > $3

Restart your sendmail and the job is done.

Configuring Sendmail on Solaris 10

Index

Part 1. Configuring Sendmail on Solaris 10
Part 2. Configuring Sendmail to Masquerade Your Messages
Part 3. Configuring Sendmail to Relay Messages to Another Server
Part 4. Configuring Sendmail to Relay Messages from Other Servers

Introduction

Whoever tried to get Sendmail up and running will agree that taming Sendmail requires black magic. I won't even try to enter into Sendmail internal and details: I don't master it and conform with being able to configure my Solaris box (and zones) to fulfill my needs. Nevertheless, I'll admit that Sendmail has got its own spell and felt compelled to keep on reading on to discover what Sendmail is capable of.

Verifying Sendmail State and Starting It Up

Solaris 10 Sendmail is configured as an SMF-managed service. To check sendmail status you can use:

$ svcs \*sendmail\*
STATE          STIME    FMRI
online         14:19:23 svc:/network/smtp:sendmail

If Sendmail were not enabled, just use svcadm to bring it up:

# svcadm enable svc:/network/smtp:sendmail

Configuring Sendmail for Open Mode

Solaris 10 Sendmail configuration is such that Sendmail will only run in local mode, thus rejecting connections from other hosts. If you want to review Sendmail default Solaris 10 configuration, you can use:

# svccfg -s svc:/network/smtp:sendmail listprop
[...snip...]
config/local_only                    boolean  true
[...snip...]

If you're curios, SMF properties are used by SFM methods. A closer examination to Sendmail startup script in Solaris 10, indeed, reveals the following:

    local=`/usr/bin/svcprop -p config/local_only $SMF_FMRI 2>/dev/null`
    if [ $? = 0 -a "$local" = "true" ]; then
        OPTIONS="$OPTIONS -C /etc/mail/local.cf"
    fi

If you want to configure your Sendmail to work in open mode you can run the following:

# svccfg -s svc:/network/smtp:sendmail setprop config/local_only= boolean: false
# svcadm restart svc:/network/smtp:sendmail

Solaris 10 Default configuration

If you inspect the default sendmail.mc file for Solaris 10 you'll find the following:

divert(0)dnl
VERSIONID(`@(#)sendmail.mc      1.11 (Sun) 06/21/04')
OSTYPE(`solaris8')dnl
DOMAIN(`solaris-generic')dnl
define(`confFALLBACK_SMARTHOST', `mailhost$?m.$m$.')dnl
MAILER(`local')dnl
MAILER(`smtp')dnl

LOCAL_NET_CONFIG
R$* < @ $* .$m. > $*    $#esmtp $@ $2.$m $: $1 < @ $2.$m. > $3

Local and smtp mailers are on and you should be able to send mail, both locally and remotely, from such a host. Unless you configure your perform additional configuration, you won't be able to connect remotely to this instance, nor using such an instance as a mail relay. Naturally, some tweaking is usually required and it will be performed with the procedure described in the following sections.

Building a Configuration File for Sendmail

To build a configuration file for your Sendmail you can perform the following:

• Temporarily disable your Sendmail:

# svcadm disable -t svc:/network/smtp:sendmail

• Go to Sendmail configuration templates directory:

# cd /etc/mail/cf/cf

• 
  
• Start with a fresh file and write your configuration down:

# cp sendmail.mc your-file.mc

Compile your file:

# /usr/ccs/bin/make your-file.cf

Test your configuration:

# sendmail -C your-file.cf -v your-email-address </dev/null

Apply your configuration:

# cp your-file.cf /etc/mail/sendmail.cf

Restart and use Sendmail:

# svcadm enable svc:/network/smtp:sendmail

A good place to start for studying Solaris 10 Sendmail is Solaris System Administration Guide: Network Services (Chapter 13).

Web Technologies on a Desktop Application - Portability Do Matter

What's the desktop application most commonly used? For a great majority of persons the answer is simple: the browser. The omnipresent browser has begun not to be perceived as an application anymore: instead, it's the container where web applications run.

Although there's still plenty of space for desktop applications,
they can't be thought as stand-alone any longer. Users continuously
rely on Internet as a source of information and desktop applications had to learn to use Internet as if it were a database.

Browsers and web developers probably learnt that before: Web
Services and the AJAX paradigm being just the last trends in the
industry. Vendors have been implementing similar technologies in their
SDKs and the boundary between web-technologies and general purpose
framework gets thinner day by day.

I just remember when JAX-* specifications were being integrated into
Java2 Enterprise Edition: nowadays you can hardly think of a Java
desktop application not leveraging JAX-WS or JAX-RS.

Many vendors have being trying to port web technologies on the desktop and the major players in this are are:

• Adobe, with Adobe AIR
• Sun Microsystems with JavaFX framework
• Google, with Google Gears

I've being intensively using Gears-powered applications just because
I'm a faithful Google applications user. I must say that I'm pretty
happy with it and that in this sense Google is probably making one step
more in this direction with its Google Chrome OS. Nowadays, although
Google Chrome still is a browser, it really acts as an environment for Google Gears applications.

As far as it concerns JavaFX, I've played a little with it with my
NetBeans and I must say that I'm impressed. Java SE and Java EE already
have all of the pieces you need to build rich internet applications and
JavaFX goes one step further: it's a platform that aims to support a
variety of devices (browsers, mobile phones, gaming consoles and so
forth).

Adobe AIR is impressive: although I never wrote any line of of code, I've seen some applications and, just as anything-Adobe, great hype is given to integration with Flex/Flash applications.

Which one should I go with?

Although every framework has got its own peculiar advantages, such a
decision depends on many factors, such as your needs and your
requirements.

One of the fundamental advantages of web applications is their
platform-independence (usually). Yes, there are many glitches depending
on the browser you're using but nowadays the situation is pretty
satisfactory, at least as far as it concerns an application
functionality. Such an independence is achieved by means of the
browser, which is the container in which such an application is
executed. Taking an application out of the browser is complex and in
that process you run the risk of reducing an application's portability.
That's the original sin of many frameworks, such as Adobe AIR.

I strongly believe in portability and that's something I'm
never going to sacrifice easily and when I do the requirement must be
compelling. That's why I always go with Java.

Let alone enterprise-level technologies supported by Java Enterprise Edition, Java gives you the basic tools you need such as:

• A powerful programming language.
• Support for Web Services (JAX-RPC and JAX-WS).
• Support for RESTful Web Services (JAX-RS)
• Support for AJAX.
• Integration with databases (JDBC, JPA)

The Java language itself has been recently enhanced by annotations
which are commonly used by specifications and frameworks (such as
Spring) to greatly reduce boilerplate code. EJB 3.0, JPA, JAX-RS,
JavaBeans Validation (JSR-303) are just examples of the
annotation-centric APIs you can use in a Java program just by applying
metadata to your class and letting the framework (or the container) do
the job. POJO-based and annotation based frameworks and APIs greatly
contributed to simplify the programming models previously used: whether
you're developing a web service, a web service client, an interaction
with a DB, an EJB, you're probably producing just POJOs. Reusing such
objects is straightforward: the boundary that existed between the
various kind of Java applications have blurred and nowadays is almost
null.

Moreover, in the incredibly vast ecosystem of Java libraries and
frameworks you're probably going to find everything you need to get the
job done.

Conclusion

When deciding the tools you're going to use to develop your next
application, always consider that there's someone out there who might
not be using your browser or your OS. If you haven't got compelling
reasons, don't shut the door in their face. Users do not understand, sometimes not even with reasons. And they'd just turn to another provider.