Java’s history with web applications is, well, complicated. Java, heavily focused on being the True Object Oriented language, went the route of containers and service-providing classes and runtime bindings and dynamic hooks and lookups well before anyone else.

The core layer which underpins a lot of the web interactions is the Servlet specification. Servlets are just classes which are wired up to handle HTTP requests. Do whatever you want there. Slap a bunch of annotations for JAX-RS on there, and it’s a restful web service. Drop a JSP file in there, a it runs as a servlet with a template. Start playing with Java Server Faces? It’s servlets all the way down.

But what happens when you want to be even more Enterprise than Java normally is? What if you want a portal application with drop-in modules that can be configured from the front end? Portlets.

Portlets are servlets for portals. It’s the Java flavor of SharePoint development. Build a CMS. Build an ERP. Build any giant enterprise product, and Portlets are there for you. They inherit huge piles of functionality important to hooking into the portal. They’re a giant mess.

Which is why Jan G was working with a “legacy portlet”. No one ever wants to start a new portlet, so they’re all basically legacy from the minute they’re written. The previous developer didn’t really understand some of the key portlet methods or concepts.

private String getFullURLbyPlid(ThemeDisplay theme, String friendlyURL) {
    Layout selectedLayout = null;
    try {
        selectedLayout = LayoutLocalServiceUtil.getFriendlyURLLayout(theme.getLayout().getGroupId(), false, friendlyURL);
        if(null != selectedLayout) {
            return PortalUtil.getLayoutFriendlyURL(selectedLayout, theme);
        } else {
            return null;
        }
    } catch (PortalException e) {
        System.out.println(e);
        e.printStackTrace();
    } catch (SystemException e) {
        System.out.println(e);
        e.printStackTrace();
    }
    if (null != selectedLayout) {
        String url = ""; //theme.getPortalURL();
        try {
            url += PortalUtil.getLayoutFriendlyURL(selectedLayout, theme);
        } catch (PortalException e) {
            System.out.println(e);
            e.printStackTrace();
        } catch (SystemException e) {
            System.out.println(e);
            e.printStackTrace();
        }
        return url;
    }
    return null;
}

The first thing to note is the method name: getFullURLbyPlid- “Plid” being the “portlet-id”. This is a long integer, and you’ll note that it isn’t a parameter to the method at all.

Skimming through, we can also spot the exception handling blocks- all of which do both a System.out.println and an e.printStackTrace(). So this guarantees that on any error, it logs out the error twice.

But the real interesting thing is this method’s approach to exception handling. In our try block, we check for a selectedLayout, then we use PortalUtil.getLayoutFriendlyURL to look up the URL for this theme.

If we don’t find a correct layout? We return null, which is going to be fun for the calling code. But if we get an exception… we essentially try again.

The second block after the try/catch is just a repeat of the try/catch: if we don’t have a selected layout, try and use PortalUtil.getLayoutFriendlyURL again.

If at first, you don’t succeed, repeat the same call and hope it doesn’t throw an exception this time.

As an added bonus, we log the same errors again, guaranteeing that we’re going to have 4 copies of every error message in the logs, which will help to make sure we really see that error in there.