Java

A Case For Using The @VisibleForTesting Annotation

Posted on by Michael Peacock

There are times when software developers are reluctant to write unit tests. I’m not going to dwell on how this attitude is ultimately self defeating, and something monstrous, but there it is. Professional developers are, at times, reluctant to write unit tests. Even though there are so many negative consequences for failing to adequately cover one’s code with clean unit tests, developers sometimes resist unit testing. I know this happens, because I’ve felt that reluctance as well. This is hard for a professional to admit without feeling somewhat dirty, but sometimes we need to admit that we’re lost before we can begin to find our way back.

For me, one of the key reasons I’ve heard the “don’t bother testing” devil make a compelling case while whispering in my ear is that I usually work with legacy code that often has very low unit test coverage. By very low, I mean typically in the range of <1% to 5%.  In these kinds of projects, essentially without any unit tests, developers are faced with the daunting task of writing a substantial amount of new unit code tests just to be able to get to the code branches that include the new code you’re adding or modifying.

Continue reading “A Case For Using The @VisibleForTesting Annotation” →

Struts 2 Dynamic Method Invocation

Posted on by Michael Peacock

java1I’ve been doing plenty of Sruts2 work lately, and have used wildcard method mapping quite a bit. Wildcard method mapping is one way Struts2 allows a developer to flexibly call methods other than execute() on your action classes. Recently, however, I had reason to check out another flexible method calling feature in Struts – Dynamic Method Invocation.

The struts documentation says this about Dynamic Method Invocation:

Dynamic Method Invocation (DMI) will use the string following a “!” character in an action name as the name of a method to invoke (instead of execute). A reference to “Category!create.action”, says to use the “Category” action mapping, but call the create method instead.

So basically, instead of changing your struts.xml file to support flexible method calling on your actions, you could simply target specific action methods my using the actionname!methodname.action format supported by DMI.

Of course, there are potential security risks with this, and Struts 2.3 adds the ability to restrict the methods that you can use DMI upon. Also, the Apache docs state clearly that wildcard method mapping is preferred over DMI.

If you have a Struts2 application that faces the internet, please consider disabling DMI, or at least providing a set of allowable DMI methods. Be aware that you have to explicitly disable by setting a constant in your struts.xml (or struts.properties) file. Since DMI enabled by default, your application could be at risk if you don’t manage how users access your action methods.  

For example, adding this line to your struts.xml will completely disable DMI:

Given that our usage involved an internal application, we found that DMI helped us solve a problem quickly and cleanly, and its use in our application outweighed the potential for abuse.