Monday, December 10, 2012

Generating Certificates With BouncyCastle

Usually, after a serious public-private key generation session, the private key would need to be stored. The obvious place would be a key store. The commonly used method to accomplish this using class:

void setKeyEntry(String alias, byte[] key, Certificate[] chain) 

You'll need at least one Certificate object to accompany the private key. You may be tempted (or already attempted) to 'skip' producing the Certificate object using this method:

void setEntry(String alias, KeyStore.Entry entry, KeyStore.ProtectionParameter protParam)

But you'll discover that a object needs a Certificate[] object passed in as well.

This led to the code below to generate the required Certificate object, just enough to fulfil the requirements to save the private key:

 private Certificate[] generateCertificateOld(KeyPair keyPair) throws Exception {
        Date startDate = new Date(System.currentTimeMillis());
        Date expiryDate = DateUtils.parseDate("01/01/2100", new String[] { "dd/MM/yyyy" });
        BigInteger serialNumber = new BigInteger(String.valueOf(System.currentTimeMillis()));

        X509V1CertificateGenerator certGen = new X509V1CertificateGenerator();
        X500Principal dnName = new X500Principal("CN=Storage Certificate");

        certGen.setSubjectDN(dnName); // note: same as issuer

        return new Certificate[] {certGen.generate(keyPair.getPrivate())};

Of course, if you have the aid of an IDE, the BouncyCastle methods used are deprecated (using v1.47). So, being a good Java coder, I've followed the advice in the BC javadocs and replaced the deprecated methods with the following equivalent code:

 private Certificate[] generateCertificate(KeyPair keyPair) throws Exception {
  X509v1CertificateBuilder certGen = new JcaX509v1CertificateBuilder(
    new X500Name("CN=Storage Certificate"),
    new Date(System.currentTimeMillis()),
    DateUtils.parseDate("01/01/2100", new String[] { "dd/MM/yyyy" }),
    new X500Name("CN=Storage Certificate"),

  JcaContentSignerBuilder contentSignerBuilder = new JcaContentSignerBuilder("SHA256withRSA");
  ContentSigner contentSigner =;
  X509CertificateHolder certHolder =;

  JcaX509CertificateConverter certConverter = new JcaX509CertificateConverter();
  Certificate cert = certConverter.getCertificate(certHolder);

  Certificate[] certs = { cert };
  return certs;

May your sanity be in check as you navigate through the waters of Java security.

Thursday, November 01, 2012

Late Adopter's Guide To JSF

'The Late Adopter's Guide' is a short composition to help developers who are busy supporting legacy (e.g. JDK 1.4, EJB 2.1, Struts 1.x, JSP) Java technologies (like me!) that they have little time to try out newer stuff or there were technical limitations trying to introduce newer stuff into existing systems. But now you are itching to learn that one technology you've been craving all along.

This post will focus on JSF (Java Server Faces).

JSF isn't a new technology but was saddled with limited functionality in its early iterations. If it were not a part of the Java EE standard, it wouldn't have survived till today. Now at version 2.1, JSF is mature and now's a good time to pick it up.

There were lots of stuff happening since version 1 till 2.1. This guide will allow you to skip the noise and brings you to the goodness of 2.1 without getting bogged down by legacy issues e.g. adding Facelets support to JSF 1.x.

My recommendation of certain APIs over others is based on personal experience, so feel free to try out others if you are compelled to do so.

So, here are the pointers to smooth JSF-ing:

1) Use JSF 2.1 (and above)
Do not use a lower version of JSF. This will save you lots of heartache. If your system does not meet the minimal requirements for JSF 2.1, then it's better to stick with existing frameworks you're currently using (if it gets the job done, why not?).

JSF 2.1 requires Java 1.5 or later, JSP 2.1, JSTL 1.2 and a Java Servlet 2.5 implementation. Tomcat 6 or 7 is recommended.

Use the latest JSF 2.1 with all its new features i.e. Facelets, parameterized methods in EL

2) Use the Mojarra JSF distribution
It's the RI (reference implementation) and stable. You can try Apache MyFaces but the real gem of JSF is not really the framework, but the component libraries.

3) Use Facelets
Forget about JSPs, even though you'll be tempted to leverage on your existing JSP skills and tools e.g. JSTL, taglibs. Facelets are just XHTML pages which is quite similar to JSPs, except that it won't allow you to embed Java code using scriptlet tags (<% %>), and you'll have to learn the new EL (expression language) syntax which is not JSTL but is almost functionally the same. However, if you have JSTL or OGNL background, then EL will be a piece of cake for you.

Facelets also has in-build support for page templating, so there's no need for 3rd-party page templating libraries like SiteMesh.

4) Don't worry about JBoss EL
There was a buzz about JBoss EL, where it lets you pass parameters to a managed bean's methods (Why was it not included in earlier JSF version? I have no idea). These feature has been incorporated into JSF 2.1

5) Manage JSF Managed Beans via Spring
If you are an ardent Spring user, then it's recommended to use Spring to manage JSF's managed beans' dependencies. JSF's dependency injection framework is decent but you'll definitely miss Spring's more powerful and sophisticated features.

Or you can go CDI if you want to go standard Java EE.

6) Use a component library
The best thing about JSF is there are so many component libraries to choose from. RichFaces, OpenFaces, IceFaces, you name it.

But if you want to skip R&D and dive right into the action, I recommend to start with PrimeFaces. But chances are that if you are comfortable with a particular library, you won't be inclined to switch. Caveat emptor?

If you don't want to use a component library, you'll be missing most of the goodness that JSF has to offer.

You can use multiple component libraries in a single web application, but it would be messy and incur unnecessary overhead in memory.


Well, I hope this abridged guide is a good start for you to look in the right direction in learning JSF. Lots of good tutorials in the wild :)

Thursday, October 04, 2012

Springing to Spring's Defense

Lately there have been less Spring-related articles posted (or probably publicized). Some took it as a sign of decline in its popularity. What about the silent majority? Well, I believe that this bunch of people are not undecided, but are already happy saving the world from oblivion using Spring. Here's my story.

This blog entry's title is funny as in actual fact, Spring doesn't need any defending. It has been around since the early 2000s, when J2EE was exciting but full of teething issues. Ever since its introduction, the Java community has been gobbling every bit of goodness that came out of Rod Johnson's team. I can happily say that even though Spring has sort of 'matured' and may be daunting to a beginner, it still does one thing really well: IoC. Other Spring sub-projects are complements that build upon an already solid framework, which is really "true reuse" in action.

So, without further adieu, here's what I like about Spring that keeps me coming back to it:

1. Solid IoC Framework
This is worth repeating here. From the simple DTD to the flexible XML schemas and config annotations, the features for applying dependency injection made almost all hand-made singletons, factories unnecessary.

2. Great utility APIs
An example: JdbcTemplate made hand-coded DataSource-Connection-PreparedStatement-ResultSet (prone to connection leaks) code blocks obsolete. However using it doesn't require using the IoC container, which is great for refactoring legacy code without introducing drastic architectural changes. There are dozens more of such utility APIs that I won't elaborate here and leave it to the reader to explore.

3. Great 'glue' APIs
You like Struts, Quartz, Velocity, Freemarker, even Axis? How about JSF, Struts2, Hibernate or JPA? Spring has the integration code necessary for you to use a wide variety of other frameworks/APIs without attempting to supercede them. Spring even complements with its own offerings e.g. Spring MVC, Spring Web Services and Spring Security. You are not forced to accept the entire Spring stack. Just pick and choose.

4.Pick & Choose
Code-wise and even package-wise, Spring now comes in modules packed in different JAR files. The Spring developers wisely decided to abandon the "1 JAR to run them all" approach and let's the users include only the minimal JAR files required to use a specific feature.

5. Unit-Testing Support
EJB3 and above has better support that its predecessors but there's still no beating Spring with its support to run the IoC container outside of the application server. I use this feature everyday :)

Well, I'll stop here. I want to continue saving the world with Spring. Have a good day.

Friday, September 28, 2012

Turbo-charge your Android emulator for faster development

I came across an article, which claims to boost the Android emulator's performance using Intel's Hardware Accelerated Execution Manager (HAXM) driver. It got me excited and I decided to verify this claim. This blog entry is my story.

My tools:

  • Android SDK r20.0.3
  • Intellij Community Edition 11.1.3

Basically, the special 'enhancement' provided by Intel is a special x86 Atom system image which utilizes the HAXM driver that enables better emulator performance. I'll not repeat the technical details here, you can access the links below for more info.

Caveat: This trick only works on Intel hardware and with the Virtualization Technology for Directed I/O (VT-d) enabled (usually via BIOS).

Also, Intel x86 system images are currently (as of this blog posting) available for Android versions 2.3.3 (Gingerbread), 4.0.3 (ICD), and 4.1 (Jelly Bean) only.

To avoid headaches, set the environment variable ANDROID_SDK_HOME to point to your Android SDK root folder before proceeding.

High-level steps:
1. Download & install relevant packages via Android SDK Manager
2. Create Android Virtual Devices (AVD)
3. Create an Android Module project in IntelliJ CE
4. Test launching the Android application using the AVDs

1. Download relevant packages via Android SDK Manager

Launch the SDK Manager and ensure the following is installed:

  • Intel x86 Atom System Images (shown below is for Android 2.3.3)
  • Intel x86 Emulator Accelerator (HAXM)

Next, you'll need to install the HAXM driver manually. Go to the Android SDK root folder and navigate to extras\intel\Hardware_Accelerated_Execution_Manager. Execute file IntelHaxm.exe to install.

2. Create Android Virtual Devices (AVD)

Launch the AVD Manager and create 2 AVDs with the same options but different Target:

  • DefaultAVD233 - Android 2.3.3 - API Level 10
  • IntelAVD233 - Intel Atom x86 System Image (Intel Corporation) - API Level 10

3. Create an Android Module project in IntelliJ CE

In IntelliJ, create a new project of type "Android Module", as shown:

Under "Android SDK", select the appropriate Android platform. You'll need to point to your Android SDK root folder in order to choose the appropriate build target. As shown below, "Android 2.3.3" is chosen:

Ensure that the "Target Device" option is set to Emulator, then click "Finish" to complete the project creation.

4. Test launching the Android application using the AVDs

Ok, we'll test using the default Android 2.3.3 AVD first.

At the IntelliJ menubar, select "Run" > "Edit Configurations...". Go to the "Target Device" section. At the "Prefer Android Virtual Device" option, select "DefaultAVD233". Then Run the Android application. After a while, you should see the emulator window with the "Hello World" message.

To run with the Intel AVD, choose the "IntelAVD233" instead.

What's most exciting is the speed of the emulator launch (timed from clicking 'Run' in IntelliJ up to the 'Hello World' message is shown in the emulator). The rough timings recorded using my notebook (Intel i3 380M, 3GB RAM):

  • DefaultAVD233 - 1m 7s
  • IntelAVD233 - 35s

Wow, that's fast (~50% faster), without tuning other parameters to speed things up even further.


Thursday, September 27, 2012

Embedding HSQLDB server instance in Spring

I was using XAMPP happily for development until I had to host it somewhere accessible via the Internet for the client to test and use. I have a VPS that only has 384 RAM, and needing to find a way fast, I decided to install XAMPP into the VPS. Because of the low RAM, when MySQL was running, Tomcat failed to start, even though the initial Java heap size was set to 64m. I managed to host the site temporarily in Jelastic, before moving to OpenShift.

I toyed at the idea of combining the database and application server instances in 1 JVM, to reduce RAM usage (compared to running MySQL + Tomcat). After searching the Internet, I came across several articles on running HSQL server instances together with Tomcat. No doubt I have to update my site to be compatible with HSQL first, but as a POC (proof-of-concept) attempt, I decided to explore the feasibility of running the HSQL server instance in a Spring container.

There are several reasons to run the HSQL server just like a bean in Spring:
1. All-in-one configuration. Everything that is needed to be configured is done in Spring. There are examples in the Net to run the HSQL instance alongside Tomcat, but this requires adding stuff to Tomcat (see links below).
2. Application server independence. 'Theoretically' (in quotes as I successfully tested this in Tomcat only), since everything is done in Spring, there's no or little that needs to be configured in the appserver.

The HSQL server 'bean' is also meant to launch an instance in network mode (not in-process e.g. mem or file). Some reasons for this:
1. 'mem' in-process access is the fastest, but is not persistent. There are other means to initiate a 'mem' data source using Spring's spring-jdbc tags, which is a better approach.
2. 'file' in-process access is persistent, but like 'mem', it can only be accessed within the Java process.
3. Network mode (hsql) is both persistent and accessible using external JDBC client tools. This is useful for troubleshooting and verification.

After reading HSQLDB's documentation, here's the code that does the HSQL server instance bean lifecycle management:
package org.gizmo.hsql.spring;

import java.util.Properties;

import org.hsqldb.Server;
import org.hsqldb.persist.HsqlProperties;
import org.hsqldb.server.ServerAcl.AclFormatException;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.context.SmartLifecycle;

public class HyperSqlDbServer implements SmartLifecycle
 private final Logger logger = LoggerFactory.getLogger(HyperSqlDbServer.class);
 private HsqlProperties properties;
 private Server server;
 private boolean running = false;
 public HyperSqlDbServer(Properties props)
  properties = new HsqlProperties(props);
 public boolean isRunning()
  if(server != null)
  return running;

 public void start()
  if(server == null)
  {"Starting HSQL server...");
   server = new Server();
    running = true;
   catch(AclFormatException afe)
    logger.error("Error starting HSQL server.", afe);
   catch (IOException e)
    logger.error("Error starting HSQL server.", e);

 public void stop()
 {"Stopping HSQL server...");
  if(server != null)
   running = false;

 public int getPhase()
  return 0;

 public boolean isAutoStartup()
  return true;

 public void stop(Runnable runnable)
The abridged Spring configuration:


Sample output when starting Spring in Tomcat:
[Server@1e893ae]: [Thread[pool-2-thread-1,5,main]]: checkRunning(false) entered
[Server@1e893ae]: [Thread[pool-2-thread-1,5,main]]: checkRunning(false) exited
[Server@1e893ae]: Initiating startup sequence...
[Server@1e893ae]: Server socket opened successfully in 7 ms.
Sep 27, 2012 9:26:23 AM org.hsqldb.persist.Logger logInfoEvent
INFO: checkpointClose start
Sep 27, 2012 9:26:23 AM org.hsqldb.persist.Logger logInfoEvent
INFO: checkpointClose end
[Server@1e893ae]: Database [index=0, id=0, db=file:d:/hsqldb/demo
base, alias=demobase] opened sucessfully in 442 ms.
[Server@1e893ae]: Startup sequence completed in 451 ms.
[Server@1e893ae]: 2012-09-27 09:26:23.395 HSQLDB server 2.2.8 is online on port 9001
[Server@1e893ae]: To close normally, connect and execute SHUTDOWN SQL
[Server@1e893ae]: From command line, use [Ctrl]+[C] to abort abruptly



Tuesday, September 18, 2012

Accessing Git Repositories using SSH behind HTTP proxy (Corkscrew, OpenSSH)

OpenShift uses SSH for its Git repositories. But at my workplace, where I need to use a HTTP proxy to access the Internet, getting TortoiseGit to connect to the Git repository seemed impossible. Out of the box, SSH can't be accessed via HTTP proxies. After vigorous searching using Google, I came across Corkscrew ( Corkscrew enables tunnelling of TCP connections through HTTP/S proxy servers.

Since I am using Windows, and happen to use Cygwin (was required by OpenShift) and TortoiseGit, here's what I did to make it work:
1. Fire up Cygwin setup, searched for 'corkscrew', download packages
2. In my Cygwin home folder (default folder for SSH settings), open file ~\.ssh\config
3. Add/modify the ProxyCommand line (replace with your proxy IP and port) as shown in the example below:

Host *
  IdentityFile ~/.ssh/libra_id_rsa
  VerifyHostKeyDNS yes
  StrictHostKeyChecking no
  UserKnownHostsFile ~/.ssh/libra_known_hosts
  ProxyCommand /bin/corkscrew localhost 8118 %h %p

4. Open TortoiseGit's Settings window, go to Network. Check the 'Enable Proxy Server' option, and add the proxy IP and port values.
5. In the SSH client textbox, enter the path to the ssh.exe file e.g. C:\cygwin\bin\ssh.exe. This assumes that you are using OpenSSH in Cygwin. Click OK.

That's it, now you can access your Git repository via SSH behind a HTTP proxy!

Spring 3.1 - Loading Properties For XML Configuration From Database

Spring makes it easy to inject values obtained from properties files via its PropertyPlaceholderConfigurer and (pre-Spring 3.1) PropertySourcesPlaceholderConfigurer (Spring 3.1). These classes implement the BeanFactoryPostProcessor interface, which enables them to manipulate the values within the Spring XML configuration file before the beans are initialized. So if you specify ${jdbc.driverClassName} to be set to the property 'driverClassName', this variable will be replaced/swapped with the value with the key 'jdbc.driverClassName' in a properties file.

Apart from properties files, the database table can also be a place to get key-value pairs. Great, so just extend the PropertySourcesPlaceholderConfigurer, and have it read a table containing the key-value pairs, populate them and we're done!

However, there's a slight problem. If the DataSource bean also relies on values obtained from a properties file (e.g. JDBC URL, username, password), and being good Springers, inject this bean to the bean class extending PropertySourcesPlaceholderConfigurer, the bean container will fail to startup properly, because the 'jdbc.driverClassName' variable cannot be resolved. Strange, but true.

The reason for this is that any bean injected into a BeanFactoryPostProcessor class will trigger bean initialization BEFORE the BeanFactoryPostProcessor classes are run. You know, dependency injection...all depending beans have to be ready before being injected into the consumer. So this creates a cyclic-dependency kind of thing. All dependencies in the XML configuration are resolved first before the BeanFactoryPostProcessor classes are run.

So, how to go about this? Well, there's a trick you can employ. A BeanFactoryPostProcessor class has access to the ConfigurableListableBeanFactory object via the 'postProcessBeanFactory' method. From this object, you can do a 'getBean' and get a reference of any bean with an id. And guess what, you can get the vaunted DataSource bean without triggering premature bean initialization.

Let's say there's a table 'sys_param' with the following data:

 --------------  --------------
 service.charge  1.5          
 rebate.amount   15.99        

The DbPropertySourcesPlaceholderConfigurer is shown here:

package org.gizmo.labs.utils.spring;

import javax.sql.DataSource;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;

public class DbPropertySourcesPlaceholderConfigurer extends PropertySourcesPlaceholderConfigurer
 public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException
  DataSource dataSource = beanFactory.getBean(DataSource.class);
  DbProperties dbProps = new DbProperties(dataSource);

The DbProperties class will make use of the DataSource reference and queries the database to get the key-value pairs:

package org.gizmo.labs.utils.spring;

import java.util.List;
import java.util.Map;
import java.util.Properties;

import javax.sql.DataSource;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.jdbc.core.JdbcTemplate;

public class DbProperties extends Properties
 private final Logger logger = LoggerFactory.getLogger(DbProperties.class);
 private static final long serialVersionUID = 1L;

 public DbProperties(DataSource dataSource)
  JdbcTemplate jdbcTemplate = new JdbcTemplate(dataSource); 
  List> l = jdbcTemplate.queryForList("select param_cd, param_value from sys_param");
  for(Map m: l)
   logger.debug("Loading from DB: [{}:{}]", m.get("PARAM_CD"), m.get("PARAM_VALUE"));
   setProperty((m.get("PARAM_CD")).toString(), (m.get("PARAM_VALUE")).toString());

To demonstrate that the values from the table are properly injected, here's the class which acts as the consumer:

package org.gizmo.labs.utils.spring;

import java.math.BigDecimal;

import org.apache.commons.lang.builder.ReflectionToStringBuilder;
import org.apache.commons.lang.builder.ToStringStyle;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.InitializingBean;

public class DbPropConsumer implements InitializingBean
 private final Logger logger = LoggerFactory.getLogger(DbPropConsumer.class);

 private BigDecimal serviceCharge;
 private double rebateAmount;
 private String smtpIp;
 public void afterPropertiesSet() throws Exception
  logger.debug("I have consumed: {}", this);

 public String toString()
  return ReflectionToStringBuilder.toString(this, ToStringStyle.MULTI_LINE_STYLE);
 public BigDecimal getServiceCharge() {
  return serviceCharge;

 public void setServiceCharge(BigDecimal serviceCharge) {
  this.serviceCharge = serviceCharge;

 public double getRebateAmount() {
  return rebateAmount;

 public void setRebateAmount(double rebateAmount) {
  this.rebateAmount = rebateAmount;

 public String getSmtpIp() {
  return smtpIp;

 public void setSmtpIp(String smtpIp) {
  this.smtpIp = smtpIp;


Last but not least, the Spring configuration (DataSource bean not shown, simplified for clarity):




The first 2 bean definitions are the BeanFactoryPostProcessor classes, and to ensure the first one is run first, the 'order' property is set (lower means higher precedence).

For the DbPropertySourcesPlaceholderConfigurer, a different placeholder prefix and suffix is used for clarity (notice the placeholders for DbPropConsumer).

So, upon Spring container startup, you should be able to view a similar output as below:
2012-09-18 00:03:14, DEBUG, org.gizmo.labs.utils.spring.DbProperties, Loading from DB: [service.charge:1.5]
2012-09-18 00:03:14, DEBUG, org.gizmo.labs.utils.spring.DbProperties, Loading from DB: [rebate.amount:15.99]
2012-09-18 00:03:14, DEBUG, org.gizmo.labs.utils.spring.DbProperties, Loading from DB: [smtp.ip:]

2012-09-18 00:03:14, DEBUG, org.gizmo.labs.utils.spring.DbPropConsumer, I have consumed: org.gizmo.labs.utils.spring.DbPropConsumer@189b939[

Monday, September 17, 2012

MySQL 5.1 - Default Time Zone

This is the easiest way to set the default timezone in MySQL, after looking through the manual ( I happen to use phpMyAdmin, an easy-to-use web UI to administer MySQL, and currently wildly popular with cloud database providers e.g. OpenShift, Jelastic and XeRound.

At the 'Home' of phpMyAdmin (I'm using version, select 'More' > 'Variables' from the top menu bar. You will be intimidated by the massive list of MySQL variables. Just type 'time' to filter the list and you should be able to find the time_zone variable ( as shown:

Click 'Edit' and enter the desired timezone offset from UTC e.g. for Malaysia (MYT) is +8:00. By default, this time_zone variable is set to SYSTEM which means MySQL will take the timezone settings from the OS.

Changes to the time_zone variable is effective immediately. To test, just run a simple query e.g. SELECT NOW() FROM SOMETABLE

Sunday, September 16, 2012

Spring 3.1 Bean Profiles

One of the most exciting new features (to me) introduced in Spring 3.1 is the bean definition profiles ( Bean definition profiles are simply bean configurations that are 'activated' based on an the existence of an indicator or marker.

A lot of examples of bean definition profiles uses the JDBC DataSource bean to illustrate its usefulness. Usually for unit testing, a DriverManagerDataSource class is sufficient, as shown below:


In order to deploy the application (typically a webapp) for active use or production, the DataSource bean is usually configured to get from a JNDI lookup, as shown:


The JNDI lookup way also requires configuring the DataSource connection pool at the application server.

Before Spring 3.1, in order to make one of the bean definitions 'active', the desired bean definition will need to be loaded last, to override the earlier appearing bean definition e.g. the 'dataSource' bean using DriverManagerDataSource will need to be in a Spring XML file that is loaded last. One of the ways to achieve this is to specify the XML file as the last file in a comma-separated value of the context-param 'contextConfigLocation' in web.xml. An Ant task may be invoked to automate a 'deletion' of this file entry so that when deployed to production, the 'dataSource' bean using JNDI lookup will be the 'active' bean. Or, just comment out the undesired bean :). It was clumsy and led to different builds for different environments.

So, how does Spring 3.1 solve this problem? Spring 3.1 allows the incorporation of the 2 different bean definitions with the same id in the same XML file, by having nested 'beans' XML elements, as shown (simplified for clarify):


A few things to note:
- The nested beans XML elements must be placed at the end of the configuration XML file
- Ensure that the Spring 3.1 Beans XSD file is used (earlier versions won't work).
- It is recommended to have one bean profile to be the default profile.

To 'activate' a bean profile, one of the ways is to pass in a system property ''. For my testing environment, I use Tomcat, so I placed this property in setEnv.bat (not in Tomcat by default, just create it under ${TOMCAT_HOME}/bin folder, and the file will be processed by Tomcat when starting up). So for testing, the value to pass is:

If the '' value is not specified, then the default profile will be the active profile.

To check or test whether which profile is active, you can get the Environment object from an ApplicationContext, as shown:

Environment env = ctx.getEnvironment();
String[] activeProfiles = env.getActiveProfiles();

In my example above, it seems that only 1 profile can be active at a time, but the Spring API allows activation of multiple profiles. Just comma-separate the profiles when specifying the value of ''. But proceed with caution as too many profiles may lead to confusion.

Friday, September 14, 2012

Default transformations for AES, DES, DESede (Triple DES) in Java

I posted on StackOverflow regarding the default transformation used for AES in Java ( Initially I couldn't find any mention of it in the JDK documentation, but I recently stumbled upon it (

I was working with a vendor who was using .NET to emulate the AES encryption on a sensitive value that my Java web service is requiring as input. He kept asking about things like what mode e.g. ECB, CBC and what padding to use e.g. no padding or PKCS. I checked the Java code used to encrypt, and the only input needed is "AES":

Cipher cipher = Cipher.getInstance("AES");

So I dug deeper into the JDK documentation and found out that to pass the mode and padding, you can pass it in one string e.g. AES/CBC/NoPadding. From the documentation, I took the recommended transformations ( and wrote a JUnit test to compare the cipher texts of the various transformation options against the default plain-vanilla "AES".

I've extended it further to include DES and DESede (Triple DES). Running it on Oracle JDK 7 yielded the following output (the transformation that produced the same cipher text value as the default transformation is in bold):

AES/ECB/PKCS5Padding: true
AES/ECB/NoPadding: Input length not multiple of 16 bytes
AES/CBC/NoPadding: Input length not multiple of 16 bytes
AES/CBC/PKCS5Padding: false
DES/CBC/NoPadding: Input length not multiple of 8 bytes
DES/CBC/PKCS5Padding: false
DES/ECB/NoPadding: Input length not multiple of 8 bytes
DES/ECB/PKCS5Padding: true
DESede/CBC/NoPadding: Input length not multiple of 8 bytes
DESede/CBC/PKCS5Padding: false
DESede/ECB/NoPadding: Input length not multiple of 8 bytes
DESede/ECB/PKCS5Padding: true

The JUnit test for reference:
package org.gizmo.crypto;

import java.util.ArrayList;
import java.util.List;

import javax.crypto.Cipher;
import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;

import org.apache.commons.codec.binary.Hex;
import org.junit.Before;
import org.junit.Test;

public class DefaultEncryptionAlgoTests
 private List<MyCipher> myCiphers = new ArrayList<MyCipher>();
 private String plainText = "Sticks and stones may break my bones but coding makes me joyous";

 private class MyCipher
  public String cipherName;
  public String[] algorithms;
  public SecretKey secretKey;
 public void generateKeys() throws Exception
  MyCipher c = new MyCipher();
  c.cipherName = "AES";
  c.algorithms = new String[] {"AES/ECB/PKCS5Padding", "AES/ECB/NoPadding", "AES/CBC/NoPadding", "AES/CBC/PKCS5Padding"};
  KeyGenerator kgen = KeyGenerator.getInstance(c.cipherName);
  c.secretKey = kgen.generateKey();
  c = new MyCipher();
  c.cipherName = "DES";
  c.algorithms = new String[] {"DES/CBC/NoPadding", "DES/CBC/PKCS5Padding", "DES/ECB/NoPadding", "DES/ECB/PKCS5Padding"};
  kgen = KeyGenerator.getInstance(c.cipherName);
  c.secretKey = kgen.generateKey();
  //DESede (or Triple DES)
  c = new MyCipher();
  c.cipherName = "DESede";
  c.algorithms = new String[] {"DESede/CBC/NoPadding", "DESede/CBC/PKCS5Padding", "DESede/ECB/NoPadding", "DESede/ECB/PKCS5Padding"};
  kgen = KeyGenerator.getInstance(c.cipherName);
  c.secretKey = kgen.generateKey();

 public void testSecurityProvider() throws Exception
  for (Provider provider: Security.getProviders())
   for (String key: provider.stringPropertyNames())
    System.out.println("\t" + key + "\t" + provider.getProperty(key));
 public void testAlgorithms() throws Exception
  for(MyCipher c :  myCiphers)
   //Default algorithm
   Cipher cipher = Cipher.getInstance(c.cipherName);
   cipher.init(Cipher.ENCRYPT_MODE, c.secretKey);
         byte[] cipherText = cipher.doFinal(plainText.getBytes());
         String defaultAlgoEncryptedHex = Hex.encodeHexString(cipherText);
   //Possible algorithms
   for(String a : c.algorithms)
     cipher = Cipher.getInstance(a);
     cipher.init(Cipher.ENCRYPT_MODE, c.secretKey);
     cipherText = cipher.doFinal(plainText.getBytes());
           String encryptedHex = Hex.encodeHexString(cipherText);
           System.out.println(a + ": " + defaultAlgoEncryptedHex.equals(encryptedHex));
    catch (Exception e)
     System.out.println(a + ": " + e.getMessage());

Anyway, to make things clear in your program, it's best to specify the full string rather than relying on default transformations in Java.

Thursday, September 13, 2012

Lazy-initializing beans in Spring: Exceptions

Lazy-initializing beans in a Spring container is generally desirable to allow for faster startup times, especially if there are lots of beans involved. However, there are some beans that must be loaded up or initialized when the application starts e.g. a background Quartz scheduler running jobs, or just doing 1st-level diagnostics or health check that writes results to a log file.

By default, all beans with scope="singleton" are initialized during container startup, but this behaviour can be changed by adding default-lazy-init="true" at the 'beans' top-level element, as shown (simplified for clarity):

To ensure a Spring-managed bean is initialized during container startup regardless of the attribute default-lazy-init="true" at the 'beans' top-level element in Spring configuration XML (or in Java code), you can one of the following:

  • Configure your bean definition to force initialization by adding attribute lazy-init="false", as shown in the example below:
  • Have your class implement the interface org.springframework.context.SmartLifecycle. This will guarantee the class will be initialized as long as isAutoStartup() is implemented to return 'true'. See the class Javadoc ( for more info.

Thursday, September 06, 2012

Logback NT Event Log Appender

I've been searching the Net for a logback-based Windows event log appender, but couldn't find any. Log4j has a built-in NTEventLogAppender, as stated in, but I came across a nice alternative in the form of log4jna (, which doesn't require placing native DLLs in a system directory.

So I based my logback Windows event log appender on org.apache.log4jna.nt.Win32EventLogAppender, to speed things up. After some trial and error, I concluded that it is better to manually create the Windows registry keys and setup some values to ensure the implementation works instead of relying on the current user's administrative rights and having the registry keys created during the appender's initialization. So the code is 'simplified'. More info @

By default, the log records will be placed under the Application log, which will contain records from other sources/systems. Viewing the records specific to your application will then require great perception or the use of filters. Since I am using Windows 7 (development) and Windows 2008 Standard (testing/production), there can be a dedicated menu item under 'Applications and Services Logs', as shown below:

To create it, just add the following using regedit: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\${Custom_Log_Name}\${Custom_Source} 

  •  ${Custom_Log_Name} with the value that will be shown under 'Applications and Services Logs'. In my example, is 'MCI-CA'
  • ${Custom_Source} with the source value that you'll need to set and specify in the logback.xml configuration file. In my example, is 'mci' 
Note: The 'source' value of the appender needs to be unique (system-wide).

Next, configure the appender in logback.xml:

            %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n%throwable

            %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n%throwable


Whack in the JARs to classpath: jna.jar, platform.jar (both from log4jna zip package), logback-core-1.0.5.jar, logback-classic-1.0.5.jar, slf4j-api-1.6.4.jar

Also, copy Win32EventLogAppender.dll (log4jna) to Window's system32 folder (e.g. C:\Windows\System32) and add a registry value (refer to .reg file in the zip file link at bottom). You can refer to for more details.

Then just get the logger instance and start logging away! I've furnished a simple JUnit test as a sample (link below). I used the system property to load a specific logback.xml file e.g. -Dlogback.configurationFile=D:\eclipse-workspaces\indigo-workspace\Sandbox\src\logback.xml

Caveat: The logback appender can be coded to cater for logback 'classic' and 'access', but I only implemented it for 'classic'. See for more details.

Accompanying files can be accessed here: