Wednesday, September 8, 2010

Java SSL Connections

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.

Friday, June 18, 2010

Mocking Frameworks – Mockito

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.

Wednesday, June 16, 2010

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

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.

Wednesday, January 6, 2010

Oracle’s Strange way of Dealing with LOB’s

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();