Character Encoding Changes in Tomcat 8 for GET Requests

HTTP GET requests (url+parameters) are treated as ASCII characters by default. Non-ASCII values, however, need to be converted to ASCII by using escape sequences. 

This conversion behavior has been changed in Tomcat 8:

• Before Tomcat 8 the default character encoding of the entire GET request was ISO-8859-1, so if your request contains UTF-8 characters (which is very common) you need to manually decode the escaped (ASCII) text back to UTF-8.
  
• Starting with Tomcat 8 the entire GET request is treated as UTF-8 by default but this can be changed to conform with the servlet specification.

Quick and Dirty jstatd Setup on Linux

What is jstatd?

 

"The jstatd tool is an RMI server application that monitors for the creation and termination of instrumented HotSpot Java virtual machines (JVMs) and provides a interface to allow remote monitoring tools to attach to JVMs running on the local host." [source]

NOTE: jstatd is not required for JMX connections;

How to setup jstatd on a Linux server?

A) login as root (told you - it's dirty)

B) create the jstatd.all.policy file in the home folder (/root) with the following content: 

   grant codebase "file:/opt/jdk1.8.0_45/lib/tools.jar" {
       permission java.security.AllPermission;
   };

     NOTE: don't forget to change the path of the JDK

C) run jstatd:

   ./jstatd -p 1099 
     -J-Djava.security.policy=/root/jstatd.all.policy
     -J-Djava.net.preferIPv4Stack=true
     -J-Djava.rmi.server.hostname=172.17.1.143

      -p                                         listen port for jstat daemon 
      java.security.policy             policy file to use (created above)
      java.net.preferIPv4Stack     use IPv4 (optional if IPv6 not used)
      java.rmi.server.hostname    listen on this interface (optional)

      NOTE: add & to run jstatd in background 

D) now you should be able to monitor this server using VisualVM.    

 

Notes on JUnit @After Annotation

Notes on JUnit @After Annotation:

• All methods marked with @After are executed
• The method named tearDown executes even if it's not marked as @After
• @After annotation is not inheritable so you need to add @After if you override the annotated method
• Remember to call super.tearDown if you override tearDown in you class
• For class hierarchies it is best to use different clean-up methods with different names, marked with @After, so they're all called automatically and you won't accidentally override them.

Interfaces, Abstract classes and Implementations

Usually you create class hierarchies like this in order to prepare for future changes:

interface -> abstract class with some implementation -> fully usable class

but if you have only one class extending the abstract one you might get rid of the abstract class and use something like this:

(marker) interface -> implementing class

Why you should get rid of the abstract class:

• less code to maintain
• simpler hierarchy design
• still have the interface to use when referencing implementing classes
• should the time come for more implementations you can refactor your class but that time:

• you will better know what to generalize and what not to
• you will have used the interface so clients no need to be changed
• you saved some time not creating middle classes

But remember this works only if you have clean, well-separated and easy to understand classes. If your class is so complex that takes weeks to understand then:

• you should not have those kind of classes at the 1st place
• but if you have, it's probably better to refactor while you're at it

It seems tempting to create fully generalized implementations but unfortunately you usually don't know how your classes will be used in the future, so skip it - if you can't at least wait for some time before doing so. Sadly I still fell sometimes :(

Of course, if you create a framework or 3rd party library there might be other factors limiting you choices so decide wisely.

More info:
http://www.codinghorror.com/blog/2004/10/kiss-and-yagni.html
http://en.wikipedia.org/wiki/You_ain't_gonna_need_it

Interesting stuff in Java Magazine July/August 2012

Interesting stuff in Java Magazine July/August 2012:

• Secure your web services with Metro, GlassFish, and NetBeans (part 1):
• NetBeans wizards help you to add some security to your web service.
• Debug live Java processes and core files with HotSpot Serviceability Agent:
• This VisualVM plugin lets you debug live and even the crashed (if you have core dumps) Java applications.
• Modify java compiler (javac) to include a new operator:
• It's easy to make small changes in javac leveraging the existing compiler.
• Threading and concurrency in Java EE:
• Don't manage threads, let containers do the work (e.g. use @Asynchronous)
• Wirelessly back up your device’s address book using bluetooth:
• Transfer data over bluetooth in the background.
• Learn Oracle Berkeley DB Java API (part 1):
• Access the embeddable key/value data store from JAVA.

  

Jotted ideas on handling errors

Just jotted down some ideas about how to handle errors

Coding:

•  log the error and the calling parameters - use system console if log fails
•  close/clean-up any resources - don't forget to handle the case if they fail
•  notify the caller about the error
•  handle errors and not swallow them
• think for the edge cases - e.g do you handle 404/301/xxx for a POST ws-call that creates a new entity?

Architecture:

• check for errors in system test - what happens:
• if resource (dbase, network, file system, etc.) is not accessible
• if resource times-out
• if resource fails
• if resource is saturated (e.g disk full, JMS queue full, etc.)
• if a failed resource comes back online - is your system still consistent?
• if rollback or any recovery mechanism fails

         NOTE: the resource can be a 3rd party application or a library

• try to be robust - restart the failing module or stop using it
• think about the whole system and not the components for error testing
• think about the impossible - you might find some cases which are plausible