Shawn on Java

Double Checking Locks for Singletons

2011-10-01T13:34:00.000-07:00

I'm not going to argue the benefits of factories and singletons in this article. The jury is in on these topics and yes, it makes sense to spend time making boiler plate code in an effort to decouple implementations from your code.

The issue with lazy loading singletons is that there are times when singletons don't behave as you expect and in my experience, this usually indicates that you may not have a singleton after all. Consider the following code:

public class AFactory
{
private static final Map<TYPE,ISomething> cache =
new HashMap<TYPE,ISomething>();
public static ISomething getInstance(TYPE type) {
ISomething ret = cache.get(type);
if ( ret == null ) {
ret = new SimpleSomething();
cache.put(TYPE,ret);
}
return ret;
}
}

The benefits of this pattern are simple. I can now code to the interface instead of the implementation, so if I want to hijack this factory for testing, I can simply add code like:

public static void setInstance(TYPE type, ISomething imp) {
cache.put(type,imp);
}

and then I can put a mock in the cache for testing. Other benefits may be to open a single connection and reuse it over and over again, or whatever.

The problem with this type of pattern is that I can get into a spot where two threads might go looking for an instance of ISomething in the cache at the same time...if no instance is there, then two separate instances can get created and the last one put in the map will be persisted. This can cause unexpected results in some cases...especially if your SimpleSomething instance has some initialization that implements a listener, or registers with a management server or some other magic.

We could avoid this simply by synchronizing the call to getInstance, but this is needless in most cases and will cause the system to slow down as threads have to wait in line to get an instance from your cache.

The solution is somewhere in the middle. I've heard the idea referred to in a couple of ways, but I like to call it a double checking lock. Have a look at the slight modification to the factory method:

public static ISomething getInstance(TYPE type) {
ISomething ret = cache.get(type);
if ( ret == null ) {
synchronized(cache) {
ret = cache.get(type);
if ( ret == null ) {
ret = new SimpleSomething();
cache.put(TYPE,ret);
}
}
}
return ret;
}

By adding a synchronized block on a cache miss, and then checking again, this forces threads accessing the factory before the cache is initialized with the implementation you are looking for to synchronize and give the application time to populate the cache. Once it is populated, no synchronization is required since subsequent calls will hit the cache for the implementation.

Java SSL Connections

2010-09-08T17:26:00.001-07:00

A while back I wrote a post on how to use the apache web client to connect to an SSL server without a globally recognized certificate. The easy way is just to import the certificate authority certificate into your cacerts file in $JAVA_HOME/jre/lib/security but in some cases you can’t do this, so I showed how I created a custom socket factory and then registered the socket factory with the Protocol class.

While trying to get an XHTML rendering library to work today, I had an issue with untrusted certificates that I needed to get working, but since the library wasn’t using the apache web client, I was a bit stuck. As it turns out, there is much lower level you can get to to make this work:

TrustManagerFactory tmFactory = 
	TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
InputStream is = ClassLoader.getSystemResourceAsStream("my.truststore");
trustStore.load(is, "password".toCharArray());
TrustManager[] tm = tmFactory.getTrustManagers();
KeyManagerFactory kmFactory = 
	KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
KeyStore keyStore = KeyStore.getInstance("pkcs12");
InputStream kis = ClassLoader.getSystemResourceAsStream("keystore.p12");
keyStore.load(kis, "password".toCharArray());
KeyManager[] km = kmFactory.getKeyManagers();
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(km, tm, null);
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

I like this way a lot better because it uses classes only from the javax.net.ssl package and work perfectly for all java based network connections. All you have to do is create your keystore/truststore files and make them available to this code somewhere in the classpath.

Mocking Frameworks – Mockito

2010-06-18T10:51:00.001-07:00

In order to do any kind of useful testing, you always have to make the odd Simulator or Mock object so that you don’t have to worry about the dependencies that are needed by the particular component you are trying to test. As long as you take the time to build your code using best practices, you should be able to put your mock object in place during the test without having to change your code for deployment. I typically use Factory classes to help me do this, but there are other patterns that you can use just as effectively. A good rule of thumb is to always code to the interface and avoid using the ‘new’ keyword for your implementations in classes that you need to test. A simple way to do this might be:

public final Class SomeThing {
  private SomeThing() {}
  private static ISomeThing instance;
  public static ISomeThing getInstance() {
    if ( instance == null ) {
      instance = new SpecificSomeThing();
    }
    return instance;
  }
  public static void setInstance(ISomeThing someThing) {
    instance = something;
  }
}

When I want to use an instance of ISomeThing, I just call:

final ISomeThing someThing = SomeThing.getInstance();

Assuming that you are comfortable with this idea, you’ve now decoupled your dependency ISomeThing from your code and now you can test whatever calls an ISomeThing without having to manipulate the world that your dependant ISomeThing lives in…you can simply Mock it.

Lets assume that your ISomeThing looks like this:

public interface ISomeThing {
  boolean isTheAnswer(int answer);
}

To create a Mock implementation of ISomeThing, you could create something like this:

public class MockSomeThing implements ISomeThing {
   public boolean isTheAnswer(int answer) {
      return answer == 64;
   }
}

So now before you test, you just make your factory return your Mock object instead of the regular implementation of the object.

SomeThing.setInstance(new MockSomeThing());

What will happen is that when your class uses the ISomeThing instance declared in the code by the factory class, it will return true if it is supplied with the input of 64, otherwise it will return false…(hitch-hiker metaphor intended)

public void testMock() {
  SomeThing.setInstance(new MockSomeThing());
  final ISomeThing s = SomeThing.getInstance();
  
  assertTrue(s.isTheAnswer(64));
  assertFalse(s.isTheAnswer(99));
}

The only issue is that now I have a really useless class in my code base that tells me that 64 is the answer. If I use a mocking framework I could do this without actually creating a mock implementation:

import static org.mockito.Mockito.*;
public void testMock(){
  final ISomeThing s = mock(ISomeThing.class);
  when(s.isTheAnswer(64)).thenReturn(true);
  assertTrue(s.isTheAnswer(64));
  assertFalse(s.isTheAnswer(99));
}

This gives me the behavior I need without actually implementing the interface. Clean and simple.

How to avoid Design – The ‘*.common.util’ package

2010-06-16T06:50:00.001-07:00

I’ve seen a lot of code that makes use of a ‘util’ package; in a limited domain, I guess I don’t really have an issue with this. A utility package would likely contain some static classes that do things like parsing strings, formatting, sorting, certain calculations…the list is endless. There are just some things that need to be static and available and rather than think about design, we pop it into a class called ‘StringFormatUtils’ and pop it into the util package so that we can remember to look for it in six month’s time.

The fatal flaw here is that looking for some obscure little function that worked once among a sea of formatters and parsers is just not going to happen. Instead what is likely to happen is that the next developer that needs the function will create another version of the function and pop it into that or another utility package and eventually you end up with an unmanageable pile of odds and ends in the code base.

Instead, the developer needs to take the time to think about the problem they are trying to solve from an abstract point of view. What is it that you are trying to do? Never mind how you intend to do it. If you are parsing data, think about a parsing architecture, ignore the details initially and then see if you have access to someone else’s wheel that they’ve already invented. Moving from how to what is the way to re-use code. If you need to make your own, then build it in the abstract and put it in its own domain that can be expanded and re-used.

I vote for a complete ban on any package named ‘util’ in favor of software that is written for a specific problem domain. If you have static analysis in your build process, I recommend a rule to root it out and eliminate it…you’ll have cleaner code.

Oracle’s Strange way of Dealing with LOB’s

2010-01-06T11:50:00.001-08:00

A LOB is a database term for a data type that is very big; a Large Object so to speak. There are times when you want to create a record that has one of these LOBs but for some reason, Oracle has some strange limitations when it comes to the size of one of these objects when you ‘insert’ them into the database.

For JDBC calls it looks like there is a max of 4Kbytes. If your insert will never be bigger than this, then stop reading, you’re fine. You can get around this limitation by using PL/SQL (wrap your insert in a BEGIN INSERT…; END;) as long as you don’t need to insert anything greater than 32Kbytes.

If you need to go higher than this, you need to do something a little strange.

Basically you need to insert a blank LOB into the record, then select the record for update and then write your data to the LOB you selected. Here’s how it goes.

InputStream is = new ByteArrayInputStream("hello world".getBytes());
PreparedStatement insert = 
   conn.prepareStatement(
      "INSERT INTO test_table (id, data) values (?, empty_blob())");
insert.setLong(1, 1L);
insert.execute();
insert.close();
PreparedStatement select = 
   conn.prepareStatement(
      "SELECT * FROM test_table WHERE id = ? FOR UPDATE");
select.setLong(1, 1L);
ResultSet rs = select.executeQuery();
rs.next();
Blob blob = rs.getBlob("data");
OutputStream os = blob.setBinaryStream(0L);
byte[] buf = new byte[1024];
int len = 0;
while ((len = is.read()) > 0)
{
	os.write(buf, 0, len);
}
is.close();
os.flush();
os.close();
select.close();

Not a whole lot of fun, but it gets the job done. I managed to find a way to get it done in a single statement but it requires PL/SQL

InputStream is = new ByteArrayInputStream("hello world".getBytes());
CallableStatement insert = 
   conn.prepareCall(
      "BEGIN 
         INSERT INTO test_table (id, data) values (?, empty_blob()) 
         RETURNING data INTO ?; 
       END;");
insert.registerOutParameter(2, Types.BLOB);
insert.setLong(1, 1L);
insert.execute();
Blob blob = insert.getBlob(2);
OutputStream os = blob.setBinaryStream(0L);
byte[] buf = new byte[1024];
int len = 0;
while ((len = is.read()) > 0)
{
	os.write(buf, 0, len);
}
is.close();
os.flush();
os.close();
insert.close();

VarArgs in Java 5

2009-10-22T10:02:00.001-07:00

I know this has been around for a while. I’ve seen it, but didn’t really know what it was. Turns out its a short hand for using arrays as an argument to a method.

If you are creating a method that takes variable arguments, it is common to supply the arguments in some sort of array. Take for instance the MessageFormat type classes:

MessageFormat.format(String format, Object[] args);

In order to use this method, the caller would have to make the call something like:

MessageFormat.format(“Hello {0}, isn’t life {1}”, new Object[]{“world”,”swell”});

VarArgs allows you to shorthand this by declaring your method like:

MessageFormat.format(String format, Object… args);

Which can then be called like:

MessageFormat.format(“Hello {0}, isn’t life {1}”, “world”, “swell”);

The only stipulation is that your vararg argument is the last in the parameter list. Java then autoboxes your arguments into an Object array for you.

Nice!

Why Test Driven Bug Fixing is Better #tdd #struts

2009-08-20T03:29:00.001-07:00

Its often difficult to convince developers that aren’t doing Test Driven Development (TDD) that its worth the little bit of extra effort to write failing tests first before touching the code. Most times, the dissenters complain about tight timelines and lack of end user benefit to ‘be bothered’ with it.

Although I am relatively new to TDD, I’ve adopted the method in every aspect of code development I can think of…especially bug fixing.

A Case Study

This is an actual example where I used TDD to fix a bug (the names have been changed to protect the ..um.. innocent).

QA reports a bug in newly developed software. In this case, the application is a struts web application and there is a radio button on a form that doesn’t have a default set; the analyst believes that it should be set to value ‘x’ by default.

The radio button is backed by a form bean class with the property ‘theRadioOption’ in the class MyFormBean which is scoped to the request for the struts action in question.

public class MyFormBean extends ActionForm
{
	private string theRadioOption;
	public String getTheRadioOption(){
		return theRadioOption;
	}
	public void setTheRadioOption(String value){
		theRadioOption = value;
	}
}

Given this snapshot of information, many experienced struts developers would say “OK, so I’ll go and set the default value in the bean…its one line of code, no need for a test.”

Before touching the code however, I created a test by extending MockStrutsTestCase and coded a very simple test:

public class FormActionTest extends MockStrutsTestCase
{
	public void testFormDefaults()
	{
		setRequestPathInfo("/GetForm.do");
		actionPerform();
		final MyFormBean form = (MyFormBean) getActionForm();
		assertEquals("Wrong Default","x", form.getTheRadioOption());
	}
}

Running the test, of course, it fails…perfect…now to fix the code.

private string theRadioOption = "x";

There, that was easy, now before we build the application and deploy the thing, I run the test again to see if it indeed passes. Surprisingly, it fails…so much for my “one line of code.”

Upon further examination, I looked in the action class that forwards to the web page. What I found was that the developer that made the form was explicitly clearing the values in the form by setting the property to null. My little ‘fix’ wasn’t seeing the light of day because the action was ‘undoing’ my default.

public ActionForward execute(ActionMapping mapping, ActionForm form, ...etc){
	final MyActionform myForm = (MyActionForm) form;
	form.setTheRadioOption(null);
	return mapping.findForward("SHOWFORM");
}

The real fix is to get rid of the explicit set to null in the action class or set it to the desired default instead of null. After setting the default in the action and running my test again I can then see that the test passes.

This test becomes part of the project now and is run during the build process every night…the issue will never return undetected. How much time did I save here? Developer builds and deploys only once instead of two or three times, QA didn’t have to re-open the bug and therefore test the feature three times instead of two, the next developer didn’t have to ask “what should this be set to by default anyway” since it is well documented in the test.

My question is how can you justify NOT putting in the little extra effort to do Test Driven Bug Fixing?

The Puf Principle: Online burndown chart generator

2009-08-07T12:53:00.001-07:00

Simple but handy… this little script creates a burndown chart for your sprint.

The Puf Principle: Online burndown chart generator

Tiles Enabling your Struts Project

2009-08-06T03:43:00.001-07:00

Tiles is a tag library framework that allows you to create templates for your JSP pages and greatly simplifies the creation of Web front ends and overall maintainability of the view layer in a JEE project.

Tiles is an Apache project, not a struts project, so it can be used with other frameworks as well. Our project is based on Struts so I’ll limit my post to how we integrate tiles with struts. If you want more information, I encourage you to check out the project website at the apache foundation where you can download the library, see examples and read documentation to your hearts content.

There are a number of ways to use tiles, we typically use a separate tiles definition xml file to define our screens and use the Tiles Plug-in in the struts-config file.

Struts comes bundled with Tiles, so if you are using struts, you already have what you need to get started.

The Request Processor

Since tiles basically intercepts forward processing in struts, you have to use an extension of the struts request processor class that handles this. This is easy to do in your struts configuration file:

<?xml version="1.0"?>
<struts-config>
  ...
  <controller 
      processorClass="org.apache.struts.tiles.TilesRequestProcessor"/> 
  ...
</struts-config>

This request processor class deals with parsing the tiles configuration and putting all the pieces together, it intercepts the ‘findForward’ method to see if the forward is a tile definition or if it is just a regular forward. You can mix tiles with simple forwards in the same implementation of struts, for instance <forward name=”success” path=”/WEB-INF/jsp/SuccessPage.jsp” /> and <forward name=”failure” path=”MyFailureTileDef” /> works just fine.

The Plug-in

The other part to configure in struts-config.xml is the Tiles plug-in which basically allows you to configure tiles for each struts module and initializes the factory for the module.

<?xml version="1.0"?>
<struts-config>
  ...
  <plug-in className="org.apache.struts.tiles.TilesPlugin">
    <set-property property="definitions-config" value="/WEB-INF/tiles-defs.xml"/>
  </plug-in>
  ...
</struts-config>

This is where you can set some of the properties of the tiles request processor. Once you have this in place, you’re all set to begin creating tiles. In this example, I set the location of the tiles definition file that I want to use in this module. Since this is the default location, it isn’t required, but in case you want to use a different file, or more likely, multiple definition files, this is how you do it. (comma separate multiple file names).

The Template

Tiles is based on JSP files that are put together at run time. Note that I said JSP files and not JSPF files. I had some trouble initially when I tried using tiles, thinking it would be good to call the template files JSP files and the pieces would be JSPF…this didn’t work and switched to using JSP for everything and just organized using folders.

Every tile has a template file, the template then uses the tiles tag library to insert page components using the configuration file which we’ll discuss shortly. Here is a simple template:

<%@ page %>
<%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %>
<html>
<head>
  <title>Simple Tile</title>
</head>
<body>
  Page Header
  <hr />
  <tiles:insert attribute="body" />
  <hr />
  Page Footer
</body>
</html>

as you can see, the template just defines a nice little placeholder for an attribute called ‘body’ which is referenced from the configuration file.

The Configuration File

A simple tiles definition looks something like this:

<?xml version="1.0" encoding="windows-1252" ?>
<!DOCTYPE tiles-definitions PUBLIC "-//Apache Software Foundation//DTD Tiles Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/tiles-config_1_1.dtd">
<tiles-definitions>
  <definition name="simpletile" page="/WEB-INF/jsp/layout.jsp">
    <put name="body" value="/WEB-INF/jsp/Simple.jsp" />
  </definition>
</tiles-definitions>

This simple definition takes your layout.jsp file and inserts a small Simple.jsp in the body marker. This file isn’t a complete HTML page, in fact it is likely just a table or a paragraph or something that gets inserted in. It makes life a whole lot easier when you want to change the navigation menu, or the header or something, you don’t have to change every file…just the layout file.

Where the definitions get interesting though is if you have a hierarchy of page ‘types’ that you want to configure, consider this definition file:

<?xml version="1.0" encoding="windows-1252" ?>
<!DOCTYPE tiles-definitions PUBLIC "-//Apache Software Foundation//DTD Tiles Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/tiles-config_1_1.dtd">
<tiles-definitions>
  <definition name="BaseDef" path="/WEB-INF/jsp/layout.jsp">
    <put name="header" value="/WEB-INF/jsp/PageHeader.jsp" />
    <put name="footer" value="/WEB-INF/jsp/PageFooter.jsp" />
    <put name="menu" value="/WEB-INF/jsp/Blank.jsp" />
    <put name="body" value="/WEB-INF/jsp/Blank.jsp" />
  </definition>
  <definition name="ClientPage" extends="BaseDef">
    <put name="menu" value="/WEB-INF/jsp/ClientMenu.jsp" />
  </definition>
  <definition name="SupplierPage" extends="BaseDef">
    <put name="menu" value="/WEB-INF/jsp/SupplierMenu.jsp" />
  </definition>
  <definition name="ClientOrderForm" extends="ClientPage">
    <put name="body" value="/WEB-INF/jsp/OrderForm.jsp" />
  </definition>
</tiles-definitions>

This definition takes the basic page layout that is common to all pages in the “BaseDef” definition and puts in the header and footer components, presumably, the layout.jsp in this definition has an insert for “header”, “footer”, “menu” and “body” such as:

<%@ page %>
<%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %>
<html>
<head>
<title>My WebSite</title>
</head>
<body>
  <tiles:insert attribute="header" />
  <tiles:insert attribute="menu" />
  <tiles:insert attribute="body" />
  <tiles:insert attribute="footer" />
</body>
</html>

Once I have all the high level parts such as the menu, header and footer coded, if I want to add an order form, I simply create a definition that extends the high level page type and then insert my body using the <put> element.

Conclusion

There are lots of ways to use tiles, this is just they way that I have always used it. It provides me with a mechanism to quickly generate the view layer and easily maintain the look and feel of my entire application by reducing all of the html overhead to one layout page and simple component pages that I can easily change when needed.

Newer versions of tiles are available and all work basically the same way, but I know that some of the architecture has changed over several iterations. If you know of newer, better ways to use tiles, I invite you to comment and share.

Getting Started with MockEJB

2009-07-16T13:10:00.001-07:00

I spent a little time recently trying to get a lightweight framework for some basic EJB unit testing with the goal in mind to reduce the number of times that I had to deploy to the application server to test new code. I had been using MockRunner for a while to test tag classes, so I thought I would try to use the EJB component which uses MockEJB as a base for testing.

The hardest part of the whole thing was really figuring out how to get the finders to work, but as usual, I was likely making it a bit harder than I had to, this is how I did it.

MyEJBTestCaseAdapter

MockRunner provides a base class for doing an EJB Test Case called EJBTestCaseAdapter, the setUp() method does pretty much everything to do with setting up your context and creating the basic environment, all you have to do is deploy your EJB classes. The base class has methods for deploying both entity and session interfaces, but I found that the deploy(BasicEjbDescriptor) method worked best for me, giving me the flexibility to deploy local and remote interfaces from multiple packages. The deploySession and deployEntity methods the the MockRunner class just provide a wrapper for the deploy method to reduce some of the complexity. So as long as you don’t have a complicated project, they should work fine for you.

I extended this test case adapter class to make my life a little easier and implemented my own deploy methods since my entity and session classes are in different packages. This just makes life a little easier because now I just have to use deployMyEntity(“Tblwhatever”):

  1: protected void deployMyEntity(String name) throws Exception
  2: {
  3:     final String interfaceName = "my.entity.package." + name;
  4:     ejbModule.deploy( new EntityBeanDescriptor(
  5:         "java:comp/env/ejb/local/" + name,
  6:         Class.forName(interfaceName + "LocalHome"),
  7:         Class.forName(interfaceName + "Local"),
  8:         Class.forName(interfaceName + "Bean")));
  9: }

Sessions are a little bit more complicated because our naming convention for Remote and Local Interfaces are a bit different:

  1: protected void deployMySession(String name, boolean local) throws Exception
  2: {
  3:     final String myPackage = "my.session.package.";
  4:     final String interfaceName = myPackage + name;
  5:     final String jndiName = name;
  6:         
  7:     if ( local )
  8:     {
  9:         jndiName = "java:comp/env/ejb/local/" + name;
 10:         interfaceName = interfaceName + "Local";
 11:     }
 12:       
 13:     ejbModule.deploy( new SessionBeanDescriptor(
 14:         jndiName,
 15:         Class.forName(interfaceName + "Home"),
 16:         Class.forName(interfaceName),
 17:         Class.forName(myPackage + name + "Bean")), TransactionPolicy.REQUIRED);
 18: }

Both of these classes make reference to an ejbModule which are provided by a method in the EJBTestCase Adapter. I set this up in my setUp() method:

  1: protected final EJBTestModule ejbModule;
  2: protected final JDBCTestModule jdbcModule;
  3: 
  4: @Override
  5: public void setUp() throws Exception
  6: {
  7:     super.setUp();
  8:         
  9:     jdbcModule = createJDBCTestModule();
 10:     ejbModule = createEJBTestModule();
 11:     ejbModule.bindToContext("jdbc/MyDS", 
 12:         getJDBCMockObjectFactory().getMockDataSource());
 13: }

Creating a Test

My TestCase simply extends this class where I deploy the sessions and entities that I will need during my test. For simplicity, I have a simple entity that has an id field that I want to update

  1: public class MyTest extends MyEJBTestCaseAdapter
  2: {
  3:   @Override
  4:   public void setUp() throws Exception
  5:   {
  6:     super.setUp();
  7: 
  8:     deployMySession("MySessionEJB", false);
  9:     deployMyEntity("Tblsomething");
 10:   }
 11: 
 12:   public void testSomething() throws Exception
 13:   {
 14:     final MySessionEJB session = EjbHomeFactory.lookup("MySessionEJB");
 15:     session.updateSomething(1L);
 16: 
 17:     final Tblsomething t = findByPrimaryKey(1L);
 18:     assertEquals(1L, t.getId());
 19:   }
 20: }

Dealing with Aspects

Assuming that your session just creates the Tblsomething entity, you likely will not have a problem running this test. But if you are looking up an entity, you will have to implement an Aspect that will intercept your finder and return something for you to play with. Here is a simple Aspect that intercepts a findByPrimaryKey method and returns a new entity that is probably suitable for a simple test:

  1: class FinderHandler implements Aspect
  2: {
  3:     FinderHandler(String entity, String finderMethod, Object[] createParams, Object pk)
  4:     {
  5: 	targetEntity = entity;
  6: 	targetFinder = finderMethod;
  7: 	entityToReturn = 
  8:           createEntityBean("java:comp/env/ejb/local/" + entity, 
  9:              createParams, pk);
 10:     }
 11: 
 12:     private final String targetEntity;
 13:     private final String targetFinder;
 14:     private final Object entityToReturn;
 15: 
 16:     public Pointcut getPointcut()
 17:     {
 18: 	return new MethodPatternPointcut(
 19:                targetEntity + ".*" + targetFinder);
 20:     }
 21: 
 22:     public void intercept(InvocationContext invocationContext)
 23:     {
 24: 	invocationContext.setReturnObject(entityToReturn);
 25:     }
 26: }

This aspect class will basically create an entity that you define using the parameters of your create method as an Object[]. The EJBTestCaseAdapter class provides this handy utility for creating an entity by looking up the class and using Reflection to find the create method and invoking it and then persisting the entity in an in memory data source that can then be retrieved using the findByPrimaryKey(Object) method in your test case.

Conclusion

Obviously, this kind of test does nothing to attempt to test the actual EJB platform with all of its intricate dependencies and configurations, but it does allow a developer to execute EJB code on their development workstations and apply TDD principles when developing EJB code.

Creating Testable Web UI Components

2009-07-09T07:55:00.001-07:00

Until recently, I always thought that the only way to test the UI components in an application was to create an end-to-end test using some kind of robot user. The reason being is that much of the UI is created using JSP pages or custom tags…these are sometimes hard to run separately outside the application, so we’ve created tests for them before but running front end tests and hoping for good results.

Since this is painful to do any detailed testing on, we generally resort to good old human testing in our QA department to make sure that the UI comes out right…obviously a bad practice.

This article goes through a case study on how to create a testable UI component using a custom tag and shows the various tests I use to validate the code.

The Tag Class

If you look at some of my old code for tag classes, you end up with some very complicated presentation logic to try and follow. My thought on this at the time was to put the complicated logic in a tag class instead of using struts logic tags and scriptlets in my JSP page. Although using a tag class is preferred to this, I now view my tag class as simply being the ‘glue’ between the data that I am trying to present and how it is presented.

What I mean by this is that, the tag class should really be used for getting a reference to the data that you want to display and passing it to the components which render the output and then passing that output to the browser. The actual tag reference is just a place holder to get that output in the right spot on the page. This model makes for cleaner, easily testable code. When you want to test the functionality of a tag class, you simply need to write a test that validates that when you pass a reference to the tag, it can find the data it needs and render an output, you don’t have to try and test all of the possible output issues involved.

The Renderer

Our application uses Struts, so a renderer is not technically part of the framework at this point as it is in say JSF. The concept is that of a component that can convert a data structure into some form of visual representation, as in say HTML. I use the term ‘renderer’ to refer to any software component that does this type of translation.

I usually start with a renderer interface since it is likely that I may need to render this component in one of many ways. I pass off the responsibility of selecting the appropriate renderer to the tag class this way I can make configurable outputs. The renderer is specific enough to be able to perform simple presentation logic, this makes the testing of a renderer component fairly straight forward.

Consider this interface:

  1: public interface ClientRenderer
  2: {
  3:     String output(Client client);
  4: }

I love using interfaces in this case because I don’t have to worry about what my output will look like to get it all wired together.  I can make a very simple implementation that will just output the clients name for starters

  1: public class SimpleClientRenderer
  2: 	implements ClientRenderer
  3: {
  4: 	public String output(Client client)
  5: 	{
  6: 		return client.getOrganizationName();
  7: 	}
  8: }

A test for this class is very simple to do and doesn’t require that you use a whole bunch of mock framework classes:

  1: public class SimpleClientRendererTest
  2: 	extends TestCase
  3: {
  4: 	public void testOutput() throws Exception
  5: 	{
  6: 		final Client cl = new Client();
  7: 		cl.setOraganizationName("testme");
  8: 
  9: 		final ClientRenderer r = new SimpleClientRenderer();
 10: 		final String out = r.output(cl);
 11: 
 12: 		assertEquals("Unexpected Output", "testme", out);
 13: 	}
 14: }

Obviously, this is a very simple example that would likely be handled with a bean:write tag, but the idea is that this renderer class doesn’t have any framework dependencies to test. It is simply a class that outputs in a predictable (and therefore testable) manner.

Testing the Tag Class

JSP Tag classes run within a framework and require references to a pageContext, a request and a response. I use MockRunner for testing tag classes since they can run within the context of my build server and don’t have to be deployed anywhere.

Since I’ve already tested the fact that my client will render the correct way, all I need to test now is that I can get the correct reference to my renderer.

  1: public class ClientOutputTag
  2: 	extends TagSupport
  3: {
  4: 	private Client clientRef;
  5: 	protected String attribute;
  6: 
  7: 	public void doStartTag() throws JspException
  8: 	{
  9: 		... // get client ref from whereever
 10: 	}
 11: 
 12: 	public void doEndTag() throws JspException
 13: 	{
 14: 		final ClientRenderer r = new SimpleClientRenderer();
 15: 		final String out = r.output(clientRef);
 16: 
 17: 		try
 18: 		{
 19: 			pageContext.getOut().write(out);
 20: 		}
 21: 		catch(IOException e)
 22: 		{
 23: 			// error
 24: 		}
 25: 	}
 26: 
 27: 	... // req'd accessors
 28: }

As you can see by this implementation, the tag class is responsible only for getting the reference and calling the renderer, you test would look something like:

  1: public class ClientOutputTagTest
  2: 	extends BasicTagTestCaseAdapter
  3: {
  4: 	public void testTag() throws Exception
  5: 	{
  6: 		final Client cl = new Client();
  7: 		cl.setOrganization("testme");
  8: 		final ClientOutputTag tag = 
  9: 			(ClientOutputTag) createTag(ClientOutputTag.class);
 10: 
 11: 		tag.setAttribute("client");
 12: 		setRequestAttribute("client", cl);
 13: 
 14: 		tag.doStartTag();
 15: 		tag.doEndTag();
 16: 
 17: 		final String out = getOutput();
 18: 
 19: 		assertEquals("Unexpected Output", "testme", out);
 20: 	}
 21: }

This is a simple example, so there isn’t much to test here. I may want to test to make sure that if I’m outputting html, that it will be valid or something like that; I would use a sax parser for that.

Why are We Embarrassed to Admit That We Don’t Know How to Write Tests? | Javalobby

2009-07-08T03:23:00.001-07:00

I found this excellent article today on writing testable code. I find one of the big problems in our organization is that we know we need to test code, and it sounds like a simple thing to do, but it is difficult thing to get your head around.

This article talks about making your code testable. It is important to differentiate between writing unit tests and writing end-to-end tests. An end to end test is a test that acts like the user for your application, and it is good for finding wiring bugs. Unit tests on the other hand, handle much simpler form of bug and a more common form of bug.

I recommend this article for all developers were not currently writing unit tests for all of their code.

Why are We Embarrassed to Admit That We Don’t Know How to Write Tests? | Javalobby

Updating the User Interface

2009-06-09T12:30:00.001-07:00

As a java developer, I’ve found the best way to actually create software is to create functionality from the software point of view. Too often, I see software that has been built from the User Interface perspective which creates a dependency on the UI for the software. Dependency on the UI is generally a bad thing because it makes it hard to test, hard to change and generally hard to understand.

I’ve made it a rule of mine to build software that does not depend on whether it is a web application, swing application, javafx application or any other environment specific application. I also try to even limit my software’s dependency on where the model is stored. I do this generally by creating an interface and more than likely a factory class to hide the implementation. This way, I can code my software to utilize the interface through the controller, rather than starting with a specific implementation that will manipulate my software component and inevitably lock me into using the implementation forevermore.

Lets say for example that I have a software component that has a counter in it. I know that I want the counter displayed to the user, but I’m not sure how yet. I also want to stick to my rule about not depending on any specific display implementation. If I follow the herd on this one, its likely that I would get a handle on my HttpServletRequest object, get the count and set it as an attribute and then create a tag to show it as an HTML element. Personally, I’ve done this hundreds of times…the struts action get the count from the counter and puts it in the request or session.

But then what happens if I want to run my software in JavaFX? I have to change the way my software works, which means that if I want to stay compatible with my current solution, I need to add a bunch of logic that says “If we are running in JavaFX do this…otherwise, do that.” This idea is really fragile and likely to be riddled with defects. Worse than that, I may re-implement the logic to run on another platform…this creates serious maintenance issues.

In another approach, lets say that I want my software to just update an appropriate display. My software doesn’t need to know about what kind of display it is, so I just add a bit of abstraction to my code that allows me to decide later how I want my display updated and then carry on writing my counter code. To do that, I create an interface:

  1: public interface CounterDisplay
  2: {
  3:    void updateDisplay(int value);
  4: }

OK. That was easy, now I may use a factory to give this Little piece to my counter software, or I may just hard code it depending on how flexible I need to be. The main thing is, that my software just knows that there is a counter display to deal with…it might be a JOptionPane message box, a JSF page or a JavaFX Scene. How we update the display isn’t important to the software component.

  1: public void incrementCounter(CounterDisplay display)
  2: {
  3:   counter++;
  4:   display.updateDisplay(counter);
  5: }

In a struts application, I may have my CounterDisplay as an action form. In this case, I could simply implement my CounterDisplay interface on the action form and then allow struts to do its thing:

  1: public class MyForm extends ActionForm implements CounterDisplay
  2: {
  3:    private int counter;
  4:    ...
  5:    public int getCounter()
  6:    {
  7:       return counter;
  8:    }
  9: 
 10:    public void updateDisplay(int value)
 11:    {
 12:       counter = value;
 13:    }
 14: }

This way, we separate the UI from the software and we can implement it anywhere.

Creating a Custom Client Server Application in JAVA

2009-05-28T11:28:00.001-07:00

I recently had a need to do something a little different from my usual J2EE thing that required me to do a little local networking directly between two clients. I needed to split a task between two users without creating a bunch of infrastructure.

Since the task was a data entry task, we were using an applet to get some data from a web service, copy that data to the users clipboard, and then call a javascript function to open a web page where the user could paste in the data. I wanted to split the task so that one user could get the data from the web service and then pass it to another user to do the javascript and pasting part.

If you read this, you will notice right off hand that there are a few things to get past here before you even get to do the client server part. Number one is that if you are running an applet and want access to the clipboard, you first have to either modify the client policy to allow this, or sign the jar file…I opted to sign the jar file. Secondly, if you want an applet to run javascript, you have to add the ‘mayscript’ parameter to your applet tag in your html page. I’m not planning on covering these topics here, but I may blog about them later.

Java Networking

The Client

A client just has to create a new instance of a Socket which has a handle to an input and output stream. All your client does is write to an InputStream and read the server response from the OutputStream. This is really quite trivial to do by using a Reader and Writer class. I used a PrintWriter to write to the server and a BufferedReader to read the response. I use another BufferedReader to get an input from the command line:

  1: public class SimpleClient
  2: {
  3:     private final Socket clientSocket;
  4:     private enum ServerState{ READY, DONE };
  5:     
  6:     public SimpleTransferClient(String server, int port) throws UnknownHostException, IOException
  7:     {
  8:         clientSocket = new Socket(server, port);
  9:     }
 10: 
 11:     public void start()
 12:     {
 13:         PrintWriter out;
 14:         BufferedReader response;
 15:         BufferedReader commandLine;
 16:         ServerState state = ServerState.READY;
 17:         
 18:         try
 19:         {
 20:             out = new PrintWriter(clientSocket.getOutputStream(), true);
 21:             response = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
 22:             commandLine = new BufferedReader(new InputStreamReader(System.in));
 23:             
 24:             String message;
 25:             
 26:             while( ( message = response.readLine() ) != null )
 27:             {
 28:                 state = TransferState.valueOf(message);
 29:                 
 30:                 switch(state)
 31:                 {
 32:                     case READY:
 33:                         out.println(commandLine.readLine());
 34:                         break;
 35:                     default:
 36:                         out.close();
 37:                         response.close();
 38:                         break;
 39:                 }
 40:             }
 41:             
 42:             clientSocket.close();
 43:         }
 44:         catch (IOException e)
 45:         {
 46:             // noop
 47:         }
 48:     }
 49: }
 50:

Making this work involves creating an instance of the SimpleClient using the server ip address and port in the constructor.

The Listener

Although a listener is not necessarily required, I thought that it would be better to launch a thread to handle the networking stuff and hand off the request to a server instance. This way, I could allow multiple clients to connect simultaneously instead of in a queue.

The listener simply creates a ServerSocket and just accepts client requests. Once it gets a client socket request, it just passes the socket off to a server thread and then goes back to listening for another client. I took a simplistic approach to this, you may want to limit the number of processes, etc to ensure that you don’t get DDOS’d to death, but in my case, this wasn’t really an issue.

  1: final ServerSocket listener = new ServerSocket(4567);
  2: while(true)
  3: {
  4:     new ServerThread(listener.accept()).start();
  5: }

As I said, this isn’t fancy, but it sets up the service, loops forever and accepts clients as quickly as it can spin off a thread. Since I was running this inside an applet and wanted some user interaction, I also put this in its own thread. Obviously, depending on what you are trying to do, this may not be necessary, but this will work in any case.

  1: public final class Listener
  2: {
  3:     private static Thread listenerThread;
  4:     
  5:     /**
  6:      * Static method to start the thread
  7:      */
  8:     public static void start()
  9:     {
 10:         listenerThread = new ListenerThread();
 11:         listenerThread.start();
 12:     }
 13:     
 14:     /**
 15:      * Static method to stop the thread
 16:      */
 17:     public static void stop()
 18:     {
 19:         if ( listenerThread != null )
 20:             listenerThread.interrupt();
 21:     }
 22:     
 23:     /**
 24:      * The actual thread class
 25:      */
 26:     private static class ListenerThread extends Thread
 27:     {
 28:         private boolean listening = false;
 29:         private ServerSocket listener = null;
 30:         
 31:         public void run()
 32:         {
 33:             try
 34:             {
 35:                 listener = new ServerSocket(4567);
 36:                 listening = true;
 37:                 while(listening)
 38:                 {
 39:                     new ServerThread(listener.accept()).start();
 40:                     try
 41:                     {
 42:                         // be nice and sleep once in a while
 43:                         Thread.sleep(1000);
 44:                     }
 45:                     catch (InterruptedException e)
 46:                     {
 47:                         listening = false;
 48:                     }
 49:                 }
 50:                 listener.close();
 51:             }
 52:             catch (IOException e)
 53:             {
 54:                 listening = false;
 55:             }
 56:             
 57:         }
 58:         
 59:         public void interrupt()
 60:         {
 61:             try
 62:             {
 63:                 if ( listener != null )
 64:                     listener.close();
 65:             }
 66:             catch (IOException e)
 67:             {
 68:                 // noop
 69:             }
 70:             
 71:             listening = false;
 72:         }
 73:     }
 74: }

So then firing up the listener would just be a static call to Listener.start();

The Server

In order to make sure that client requests don’t get queued up, we implement the actual server as a thread as well. This way, when a client connects, the listener creates a new ServerThread and then goes back to listening.

The server is almost identical to the client in terms of code. Both sides use a plain old Socket and read and write from an output stream. I used a PrintWriter for my output and a BufferedReader for my input:

  1: public class ServerThread
  2: {
  3:     private final Socket clientSocket;
  4:     
  5:     private enum ServerState{ READY, DONE };
  6: 
  7:     public ServerThread(Socket socket)
  8:     {
  9:         super("ServerThread");
 10:         clientSocket = socket;
 11:     }
 12: 
 13:     public void run()
 14:     {
 15:         PrintWriter output;
 16:         BufferedReader response;
 17:         
 18:         try
 19:         {
 20:             output = new PrintWriter(clientSocket.getOutputStream(), true);
 21:             response = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
 22:             
 23:             ServerState state = ServerState.READY;
 24:             String message;
 25:             output.println(state.toString());
 26:             
 27:             while(! state.equals(ServerState.DONE) && (message = response.readLine()) != null )
 28:             {
 29:                 if ( "quit".equalsIgnoreCase(message) )
 30:                     state = ServerState.DONE;
 31: 
 32:                 output.println("You Said: " + message);
 33:                 output.println(state.toString());
 34:             }
 35:             output.println("Closing Connection...");
 36:             output.close();
 37:             response.close();
 38:             clientSocket.close();
 39:         }
 40:         catch (IOException e)
 41:         {
 42:             // noop
 43:         }
 44:     }
 45: }

Java Applets and Javascript

2009-04-24T10:18:00.001-07:00

Everyone knows that you can use javascript to manipulate java applets.

Take for example, I have an applet with a public method called doSomething(). All one has to do to execute this method from javascript is to get a handle on the applet and call the method:

I found out today that you can use java applets to fire javascript functions and manipulate the DOM in the browser with a little extra tweaking. The Java plugin comes with some classes in the ‘netscape’ package that allows for this interaction…(yes it works in IE also)…All you have to do is get a handle on the window that holds the current applet. Consider the following example:

public class SomeApplet extends JApplet
{
public void init()
{
     final JSObject jso = JSObject.getWindow(this);
     final Object out = jso.call(“someFunction”,
               new Object[]{ “testParam” });
     System.out.println(“Output from function: “ + out);
}
}

<script type=”text/javascript”>
   function someFunction(msg) {
       alert(msg);
       return “the output”;
   }
</script>

This simple example calls the javascript function from within the applet and read back the output of the function as an Object. The one thing that you must do is enable scripting of the applet:

<applet … mayscript />

If you don’t add the mayscript parameter to your applet, you will get a JSException that tells you nothing.

InfoQ: Craftsmanship and Ethics

2009-02-13T13:45:00.001-08:00

This is a fabulous video on good practices as a software developer and as a software development organization. It highlights a number of Do’s and Don’ts that all developers should follow.

If you are a developer, you need to watch this.

The video discusses concepts such as Discipline in software development such as:

Short Iterations; design-build-refactor-repeat
Don’t Wait for Definition; be part of the requirements definition by releasing executable code
Abstract away Volatility; separate things that are likely to change from things that are not likely to change
Decouple; build interfaces and build to the interfaces
Find ways around Blocks; continuously remove impediments
Keep architectures simple; I had to look up what ‘turgid viscous’ meant, but make architectures solve problems that are within the scope of the present project.
Improve Incrementally; fix problems a little at a time.
Avoid Grand Re-designs; don’t confuse this with incremental improvement, this just means that you leverage old product to make new product.
Progressive Widening & Progressive Deepening; I love these two terms. Widening is creating fully functioning features one at a time and deepening is a form of refactoring to add the layers required to limit dependencies. “First make it work, then make it right, then make it fast.”
Don’t write bad code; take the time to get the code right, don’t speed through to make a release.
Clean your code; messy code exists over a long term and causes problems with people working on it later and causes productivity to drop. “Every line of Code is what you expect it to be.” Keep functions small and simple, name things well, use proper formatting, etc.
Test Driven Development; three rules (1) Don’t write any production code until you’ve written a test for it, (2) don’t write any more test than is likely to fail, (3) then don’t write any more code than what would pass the test. This cycle ensures that you’ve always got testable code.
QA Should not find anything; don’t use QA to find our defects.
100% code coverage; make sure all code is considered tested.
Avoid debugging; using test driven development helps this, debugging is a way of helping you understand how your own code works. Using a test to do this is a better and more persistent method of doing this.
Manual Test Scripts are Immoral; Automate test scripts and make them part of the deliverable.
Define Done; Make sure software id done at the end of an iteration. Use “all tests pass” as a default definition.
Test Through the right Interface; Make sure that you don’t need the GUI to test your application.
Apprenticeship; make sure new programmers are not left to develop their own bad habits.
Use Good Tools; this goes without saying. If you’ve ever done any woodworking you know that good tools make all the difference in the final product.

InfoQ: Craftsmanship and Ethics

Web Security via web.xml

2009-02-11T03:55:00.001-08:00

I think web.xml is often overlooked for a great many configuration options. Personally, I’m guilty of limiting my use of the deployment descriptor to servlet, filter and tag configuration. I don’t like to see the file get messy I guess.

This article talks about the authentication configuration options that can be used in web.xml. This was something that I usually took care of in the web server configuration, not so much in the application server layer…but it looks like there are quite a few options here.

Understanding Web Security Using web.xml Via Use Cases | Javalobby

Using HttpClient with Unique SSL Requirements

2009-02-03T17:40:00.001-08:00

In looking at the HtmlUnit library as a means to do headless front end testing as part of our build process. I quickly ran into to very large problems that I had to overcome.

Firstly, the default HttpClient behaviour when dealing with un-trusted server certificates is to throw an exception when connecting. Since our development server doesn’t have a trusted certificate and its a waste to buy one for development, I needed a way to be able to get my build server to trust my homemade server certificate. Luckily, I can tell the webclient to use insecure ssl, but I thought perhaps that this might be a little shot-gunnish.

Secondly, many of our modules require a client side certificate to be able to connect from the web browser…another behaviour which isn’t the default from the HttpClient.

After a little hunting, I found the SSL guide on the HttpClient project site…(image finding it there of all places). I found that the explanation wasn’t so good on the page except it links to the source file of an AuthSSLProtocolSocketFactory.java that made things quite a bit clearer. Allow me to explain.

HtmlUnit uses the commons HttpClient to download pages. The client uses the Protocol class when making connections to servers. In order for me to be able to change the behavior of a connection, the easiest way to do this is to supply the client with an alternate protocol class to use when connecting with a server…this is a lot easier to do than you think.

I basically replicated the AuthSSLProtocolSocketFactory class mentioned earlier and then I used it to construct an instance of a Protocol class. Then I registered my new Protocol to handle “https” requests. I had a bit of trouble using the java keystore for my client certificate, so I had to add a small change to allow me to handle PKCS12 keystore instead, which works just fine.

Once you have the socket factory created, then all you do is create a ‘new’ protocol to handle https and register it with the framework:

  1: final Protocol authhttps = new Protocol(
  2:     "https", 
  3:     new AuthSSLProtocolSocketFactory(
  4:         keystoreUrl,
  5:         "password",
  6:         truststoreUrl,
  7:         "password"), 
  8:     443);
  9: 
 10: Protocol.registerProtocol("https", authhttps);

Once this is done, you simply code your unit test. See the ‘Getting Started’ link at http://htmlunit.sourceforge.net.

HttpClient - HttpClient SSL Guide

Other Media By Object Mentor People

2009-01-28T09:52:00.001-08:00

Some more videos from the Object Mentor folks…

Other Media By Object Mentor People

InfoQ: The Principles of Agile Design

2009-01-28T09:07:00.001-08:00

Interesting video about OO design…should see it.

InfoQ: The Principles of Agile Design

Open source Java projects: Terracotta - JavaWorld

2009-01-28T05:13:00.001-08:00

Terracotta is an open source clustering system for Java that supports Tomcat and Weblogic (mentioned specifically) but I imagine it would support any Java Server implementation. It uses bytecode instrumentation to examine shared attributes and submits only changed values to the terracotta server.

Its a decent strategy for performing replication, as out of the box, Oracle’s OC4J will do replication either at the end of each request or on attribute update. Depending on how developers update session attributes, you may be forced to replicate everything at the end of every request…very expensive.

Terracotta seems to have an optimized method of doing it. I’ve never implemented it, but I may give it a shot and see what it can do.

Open source Java projects: Terracotta - JavaWorld

Essential Java resources

2009-01-27T07:43:00.001-08:00

Here is a list of blogs, packages, websites, books and tools that should be on the list of all java developers everywhere. Comments on the original blog are welcome and encouraged.

Essential Java resources

Enterprise Java Community: Java Pseudo Transactions With Non-Transactional Resources

2009-01-27T06:15:00.001-08:00

This article talks about implementing transactions without JTA aware resources in a pseudo transaction.

Enterprise Java Community: Java Pseudo Transactions With Non-Transactional Resources

Rich Internet Applications

2009-01-23T03:35:00.001-08:00

Podcast compares several RIA platforms.

The Java Posse

An Overview of Servlet 3.0

2009-01-21T03:16:00.000-08:00

An Overview of Servlet 3.0 Javalobby

Looks like java EE 6 will have a new Servlet class that is intended to simplify servlet and filter deployment as well as add some async functionality to help support web services.

The web.xml file will still be around, but you will be able to choose between one big xml file and several 'fragment' files. You will also be able to configure your servlets using annotations instead of the standard descriptor file. This may be handy for implementing listeners where you will be able to define a context listener by adding @WebServletContextListener.

Async calls and enhanced security are in the mix too and will be available in Java EE 6.