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 the following Gist showing the relevant parts of the template to implement the solution.

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

This was originally posted on blogger here.

1 comments captured from original post on Blogger​

pauldevine said on 2017-11-12

Thanks for this.

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.*.

This was originally posted on blogger here.

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.

This was originally posted on blogger here.

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

Docky seems much simpler, robust and reliable so far. Everything works pretty much out of the box, my dock contains 5 static launchers right now (Skype, Google Chrome, Firefox, Last.fm, IntelliJ IDEA and SmartGit/Hg) and then some utilities offered by Docky.

Regular applications, where binary executable file is used to launch and run the program, are usually working without any issues in Docky, However, some special applications, script- or Java-based, may have problems with dock. In my case, this happened with newest SmartGit/Hg 4. While I was able to pin it into launcher (SmartGit/Hg's distribution for Linux contains shell script to generate the *.desktop launcher file), I had problem with duplicate icon in the dock, once program was launched. Docky did not recognize the application's windows and thus was considering it to be a separate application then the pinned icon.

Problem is the way in which Docky is able to match the launchers (pinned icons) to actual application's windows. Docky's options are sometimes limited, in case of SmartGit/Hg 4, the Ubuntu launcher runs a shell script ...smartgithg-4_0_1/bin/smartgithg.sh, which then starts a JVM which as an OS process looks like java -D ... -jar ...bootloader.jar. Moreover, the title of the window is not static, SmartGit/Hg places the name of project into it. So Docky has obviously problem to match new OS process to the icon in dock.

After a while, I was able to get the solution: use StartupWMClass hint in the launcher file, to help Docky identify the application's window. I found the hint in Docky's bugtracker pages. Necessary steps:

1. find out the value for StartupWMClass:

   1. start SmartGit/Hg 4,

   2. start terminal, run xprops,

   3. with cursor (changed to cross by xprops command) click on title of the SmartGit/Hg main window,

   4. look into terminal, xprops finished, dumping a lot of information. The one we're looking for is at the bottom:

      ...
      ET_WM_SYNC_REQUEST
      WM_CLASS(STRING) = "SmartGit/Hg", "SmartGit/Hg"
      WM_ICON_NAME(STRING) = "Liferay - SmartGit/Hg 4.0.1 "
      ...
      

2. open ~/.local/share/applications/syntevo-smartgithg.desktop -- the default launcher file for SmartGit/Hg 4,

3. add following line to the file:

   StartupWMClass=SmartGit/Hg
   

Then Docky will be able to match your SmartGit/Hg windows to pinned icon and you won't see double icon in dock any more.

While looking at jetbrains-idea.desktop launcher file for IntelliJ IDEA, I've noticed it uses the same approach and I've never had a problem with it in Docky, so I assume this approach may be reliable in a longer run.

Btw. MenuLibre has been very useful to manage all the launchers in Ubuntu. With Unity, the old-fashioned application's categories are not present in the UI any more. If allows you to change the *.desktop files manually in built-in editor or use GUI to form the file content's for you (selecting the executable file and icon using pop-up dialog etc.)

This was originally posted on blogger here.

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).

For simple tests and classes, you'll be just fine with just instantiating your tested class, calling the method and verifying the returned result:

public class CustomJspRegistryImplTest {

    @Test
    public void testGetCustomJspFileName_noExtension() {

        Assert.assertEquals(
            "/some/absolute/non_extension_page.test-context",
            _customJspRegistry.getCustomJspFileName(
                "test-context", "/some/absolute/non_extension_page"));
    }

    private CustomJspRegistryImpl _customJspRegistry =
        new CustomJspRegistryImpl();

}

But what if code inside getCustomJspFileName() calls some other methods, how to ensure we're not testing their implementation instead of ours? The answer is a technique extensively used in software development: mocking.

Wiki link above contains some basic examples of static methods' mocking. When you need to mock some instance method's call, you can use either:

1. already, fully mocked classes from libraries like spring-test, available in Liferay out of the box. Examples could be MockServletContext or MockHttpServletRequest, allowing you to tailor the objects as you need.
2. use PowerMock and Mockito libraries to mock individual calls on any class objects:

private HttpServletRequest _getRequestWithApplicatoinAdapter(
    String adapterServletContextName) {

    MockHttpServletRequest request = new MockHttpServletRequest();

    ThemeDisplay spyThemeDisplay = spy(new ThemeDisplay());

    request.setAttribute(WebKeys.THEME_DISPLAY, spyThemeDisplay);

    Group spyScopeGroup = spy(new GroupImpl());

    UnicodeProperties spyProps = spy(new UnicodeProperties());

    doReturn(spyScopeGroup).when(spyThemeDisplay).getScopeGroup();
    doReturn(spyProps).when(spyScopeGroup).getTypeSettingsProperties();
    doReturn(adapterServletContextName).when(spyProps).getProperty(
        "customJspServletContextName");

    return request;
}

As you can see, we need to provide particular typeSetting in scope group of given HTTP request. Every time we want to mock an object's method call, we need to do two things:

1. get instrumented version of the object:
   • ThemeDisplay spyThemeDisplay = spy(new ThemeDisplay());
2. say which methods we want to mock and how:
   • doReturn(spyScopeGroup).when(spyThemeDisplay).getScopeGroup();
   • this line could be read as:
     • whenever method getScopeGroup() is being called on our instrumented object (spyThemeDisplay), we'll get object spyScopeGroup
     • returned object spyScopeGroup could be (and in our example is) further mocked as well.

Powermock documentation contains a ton of useful examples and provides a very god entry point. Complete source of the test class I've used in this post could be found on Github.

This was originally posted on blogger here.

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.

This was originally posted on blogger here.