Cloud Formation - Boolean as Parameter in template

You've most likely noticed, that Cloud Formation does not support any Boolean type for template Parameters (see AWS docs). You will get:

Template format error: Unrecognized parameter type: Boolean

But many of the resources have Boolean parameter, like AWS::RDS::DBInstance -> MultiAZ or its StorageEncrypted property.

Solution? Use following workaround:

• a "yes" / "no" selection Parameter with String type (or really any two values which make sense to your use case / language), 
• a Condition (converting String to a semi-Boolean) and 
• in the resource's property, use the intrinsic function Fn:If to convert semi-Boolean result of the condition into real Boolean

Note that you cannot use the Condition directly as the property's value, using e.g. "Ref" + its name - you'd get a validation error, even if you defined "DependsOn": 

Unresolved resource dependencies [DbRdsMultiAZCondition] in the Resources block of the template

See following Gist showing the relevant parts of the template to implement the solution:

	{
	...
	"Parameters": {
	"DbRdsMultiAZ": {
	"Type": "String",
	"Description": "Specifies if the RDS instance is deployed in multiple Availability Zones.",
	"AllowedValues": [
	"yes",
	"no"
	],
	"Default": "no"
	}
	},
	"Conditions" : {
	"DbRdsMultiAZCondition" : {"Fn::Equals" : [{"Ref" : "DbRdsMultiAZ"}, "yes"]}
	},
	"Resources": {
	"DbRdsLiferayInstance": {
	"Type": "AWS::RDS::DBInstance",
	"Properties": {
	...
	"MultiAZ": { "Fn::If" : [
	"DbRdsMultiAZCondition",
	true,
	false
	]}
	}
	}
	}
	}

view raw Cloud Formation boolean Parameter hosted with ❤ by GitHub

It's long and ugly, but it works :-)

Testing plugins with Ivy using Powermock

Recently, liferay-plugins SDK (and also its EE version) switched to using Ivy to manage some of the dependencies. Even when there are still static dependencies taken from defined portal -- Ivy dependencies are added to the lib/ext and ROOT/WEB-INF/lib ones, see build-common.xml -- this makes adding dependencies into plugins so much easier and cleaner.

Since I'm working on some plugins, I wanted to cover the functionality properly using JUnit tests, using  Powermock and Mockito. Here are necessary steps to get those libraries on test classpath in plugins SDK:

(1) open ./ivy.xml
(2) add following dependencies:

...
<dependency conf="runtime" name="xml-apis" org="xml-apis" rev="1.4.01" />
<dependency conf="test" name="junit" org="junit" rev="4.11" />
<!-- CUSTOM BEGIN -->
<dependency conf="test" name="mockito-all" org="org.mockito" rev="1.9.5" />
<dependency conf="test" name="powermock-api-mockito" org="org.powermock" rev="1.5" />
<dependency conf="test" name="powermock-api-support" org="org.powermock" rev="1.5" />
<dependency conf="test" name="powermock-core" org="org.powermock" rev="1.5" />
<dependency conf="test" name="powermock-reflect" org="org.powermock" rev="1.5" />
<dependency conf="test" name="powermock-module-junit4" org="org.powermock" rev="1.5" />
<dependency conf="test" name="powermock-module-junit4-common" org="org.powermock" rev="1.5" />
<dependency conf="test" name="javassist" org="javassist" rev="3.12.1.GA"/>
<!-- CUSTOM END -->
...

I'm sure there may be more combinations of dependencies, this is the first that fully worked for my basic tests using classes and calls like @PrepareForTest, @RunWith(PowerMockRunner.class), PowerMockito.mock(...) and Mockito.*.

Want lambdas with jdk6? Here's an IDEA

All Java people are looking forward to jdk8 to bring more functional-like syntax to the language, but it will take some time before we'll really be able to code like that day to day. It may take years, before jdk8 gets fully adopted as a standard (how many of you already use jdk7 in production these days?) Till then, we'll still have to write all the verbose code around -- if you want to stick with Java language, of course.

Want to try how it will look like in your code today? Get IntelliJ IDEA 12. This is how my source code looks in it (Java 1.6.0_38-b05):

When I hover the grayed code, real syntax comes up:

Pretty cool, huh?

Extremely improves readability, when your anonymous class method's body is just one line return statement. And that's pretty often, when you're e.g. mocking method calls in unit tests.

SmartGit/Hg 4 and Docky in Ubuntu 12.10

Since the first time I started to use Ubuntu as a primary operating system on my work laptop, I liked the possibility of endless customization possibilities I could make in the OS to have the UI match my preferences. Although I trust UX engineers from Canonical to do the work for me in most cases, sometimes you like to use few things differently or simply try new cool widget in your day to day work.

One major customization that I've started to use is dock at the bottom or the screen. It keeps my most-used applications and aggregates their windows (when they are running). This functionality is of course inspired by great dock present in OS X systems.

I've used AWN in previous versions of Ubuntu, quite happily except few quirks, but in my newest 12.10 release, I've switched to Docky. I came across it on some Internet forum where I was looking for solutions to my issues with AWN in freshly installed system.

Docky bar at the bottom of the screen

Creating unit tests in core Liferay sources

Liferay has been catching up lately on the tests coverage. Many improvements have been made in the trunk located in liferay-portal / master branch on GitHub and since I've been fixing some things recently, I've included unit test for the changed class as well.

Quick start how-to:

1. read Liferay testing documentation to get the basic picture,
2. create your unit test in portal-impl/test/unit/.../<your_class>Test.java,
3. create test methods as usual with JUnit 4.x,
4. run the test and see results:

• cd portal-impl,
• ant test-class -Dclass=CustomJspRegistryImplTest,
• note that only the name of the class is used, not the full name including package.

Testing just a single class at a time seems to be necessary, executing ant test-unit to run all existing unit tests seems to be time consuming (from minutes to tens of minutes).

OpenDS -- testing LDAP server

Since LDAP integration is part of most modern servers and Liferay also supports this directory service protocol, development on local machine gives us the challenge of testing the integration, without installing (or using remote) full-blown LDAP server. Since I've been implementing some LDAP classes changes recently and had to test them manually, I was looking around what could I use easily use for this purpose.

I was on Windows that time, but using Ubuntu simultaneously when possible, so the tool would ideally be available on both operating systems. Among other requirements, I wanted the obvious:

1. easy and quick installation,
2. quick startup with small footprint on computer's performance,
3. sample data (users) generation,
4. free of at low cost.

After some googling, I came across OpenDS, which seemed to fullfil all my requirements. It's written in  Java, does not require OS installation (just unzipping) and initial server setup is quick and easy.

Zipped package contains setup and setup.bat, launching GUI setup tool. You can create default LDAP structure (with sample data, if you wish) and within 2 minutes, you have LDAP server up and running, ready to be accessed by your LDAP clients. OpenDS contains also simple GUI browser, allowing inline modifications to entries.

I can only recommend.