Resize EC2 Volume (without Resizing Partition)


You would like to resize a volume attached to an EC2 instance.


Do the following:

  • Create a snapshot of your volume (instructions)
  • Stop your instance
  • Go to EBS / Volumes and select Actions / Modify Volume

Modify Vol

  • Enter the new size for your volume (note you can only ever make the volume larger) and click on Modify


  • Wait for the modification to be complete (this might take a while, like 30 min or so)
  • Start your instance

Now, if everything went well, you should have more space available on the disk for the virtual machine. To confirm this, run:

df -h

You should see the new size of the volume as the size of your main partition:



  • If the size of your partition, does not match the size of the volume, you probably need to resize your partition (instructions).
  • Resizing the partition is a very painful process, that I think should best be avoided at all costs. I think for this it helps if the EC2 instance attached to the volume is stopped when the resize is performed. Assure that this is the case before you do the resize.
  • If you forgot to stop your instance, and need to do a partition resize, there is a little workaround. Wait for six hours, then resize your volume again (this time while the instance is stopped). Then, it hopefully adjusts your partition size to the correct size.
  • In the above, you might be able to start up your instance even while the new volume is still optimizing. I haven’t tested this though but my guess is that it would work.


Library for Parsing multipart File Upload with Java

One of the most convinient ways to upload files from the Web Browser to the server is by using file inputs in HTML forms.

Many web servers come with preconfigured modules for parsing this data on the server-side. However, sometimes, your HTTP server of choice might not offer such a module and you are left with the task of parsing the data the browser submits to the server yourself.

I specifically encountered this problem when working with a Netty-based server.

The form will most likely submit the files to your server as part of a multipart/form-data request. These are not that straightforward to parse. Thankfully, there is the library Apache Commons FileUpload which can be used for this purpose.

Unfortunately, processing some arbitrary binary data with this library is not very straightforward. This has motivated me to write a small library – delight-fileupload –  which wraps Commons FileUpload and makes parsing multipart form data a breeze. (This library is part of the Java Delight Suite).

Just include the library and let it parse your data as follows:

FileItemIterator iterator = FileUpload.parse(data, contentType);

Where data is a binary array of the data you received from the client and contentType is the content type send via HTTP header.

Then you can iterate through all the files submitted in the form as follows:

while (iter.hasNext()) {
 FileItemStream item =;
 if (item.isFormField()) {
   ... some fields in the form
 } else {
   InputStream stream = item.openStream();
   // work with uploaded file data by processing stream ...

You can find the library on GitHub. It is on Maven Central. Just add the following dependency to your Java, Scala etc. application and you are good to go:


You can also check for the newest version on the JCenter repostiory.

I hope this is helpful. If you have any comments or suggestions, leave a comment here or raise an issue on the javadelight-fileupload GitHub project.



Java: Find all instances of System.out.println()

A good Java application should print only the absolute necessary to standard out. Not to do so can mean a serious hit in performance and can make it difficult to debug issues.

Unfortunately either we ourselves or our colleagues put System.out.println() statements in the code and then forget to remove them.

Here are two solutions how to find all those nasty statements.

Solution 1: Do a Full Text Search

Use your IDE and search for all occurrences of the string “System.out.println()” in your code. In eclipse this can be done through Menu / Search / File …

Make sure to use *.java for the file name pattern.


Solution 2: Put a Breakpoint in PrintStream

The above solution might not be practical if there are many System.out statements in the code which are legitimately there. In that case, you can also put a break point into the Java standard class PrintStream.

In eclipse, open the search for class dialog (Ctrl+Shift+t) and type in the class name PrintStream from the package


In this class, find the print(x) method and add a breakpoint:


Then run your program in debug mode. You can then find the places where System.out is called from the stack trace.


Understanding Creation of GWT Serialization Policy Files (.gwt.rpc)

Today I deep-dived a bit into how GWT creates and reads Serialization Policy files. These are the .gwt.rpc files which are generated beside the JavaScript files for GWT modules.

Chiefly, I learned two things:

  • The .gwt.rpc files are only used by the server. The client never reads them.
  • The .gwt.rpc files are generated in the ProxyCreator class.

I have listed some further classes and links below.

GWT Framework Classes

ProxyCreator: Creates the .gwt.rpc file

RemoteServiceProxy: Manages calls to services

ClientSerializationStreamWriter: Write serialization on client for server

ClientSerializationStreamReader: Read responses from server on client

Serializer: Interface for serialization contract for class


The GWT RPC Wire Protocol


Sandboxing JavaScript in Java App – Link Collection

The JVM is by design an insecure environment and it is generally difficult to run untrusted code in a sandboxed environment.

However, it seems that is relatively easy to sandbox JavaScript code running in Oracle Nashorn. The instructions are here. Strangely, this was not easy to find through a Google search.

Below I have listed some further sources on Sandboxing JavaScript and Java code. Although there is plenty of material on Rhino, I would not recommend using this engine. I think Nashorn has been designed with support for Sandboxed code in mind from the very beginning while in Rhino the functionality feels kind of bolted on.

UPDATE I have implemented two little libraries which takes care of the grunt work of sandboxing Nashorn and Rhino code in Java:

Nashorn Sandbox (on GitHub)

Rhino Sandbox (on Github)

Sandboxing JavaScript


Restricting Script Access to Specified Java Classes: From the Oracle Nashorn docs. Shows how to restrict access to specific Java classes.


Class ContextFactory: Useful for monitoring and setting restrictions on Rhino code.

Method initSafeStandardObjects: Useful for creating sandboxed Rhino code.

Rhino Sandbox: A small library for sandboxing JavaScript code running in Rhino.

Sandboxing Rhino in Java: Blog post

Securing Rhino in Java6: Blog post


Sandboxing JavaScript Execution in Java: Blog post

Sandboxing Java

Example Code Monitoring Threads: Example code how thread CPU usage can be monitored.

The Java Sandbox: A library for sandboxing any Java code. Might be useful to sandbox the Java code with runs the script.

Use Signed SSL Certificate with Java

It seems to me like every time I have to do something that has to do with SSL certificates – be they self-signed or signed by a certificate authority – things do not go smoothly. I only do this from time to time, so I am by no means an expert; but I do believe my difficulties result to some degree from the intrinsic complexities within SSL and the systems which support it.

I have created another guide which walks step by step through the process of configuring a Java key store with a signed SSL certificate. If you do want this to succeed, note that you have to follow every step precisely. Even minor omissions can lead to errors (believe me, I’ve tried it myself).

  • Download Portecle (from here) and Unzip it
  • Start portecle.jar by double clicking it
  • Go to File / New Keystore

  • Select JKS and click [OK]
  • Go to Tools / Generate Key Pair

  • Select Algorithm RSA and Key size 2048
  • Increase validity from the default 356 to 1000 or more days

  • In Common Name provide the domain or subdomain of the domain you want to protect
  • Provide some input for all other fields – do not leave any empty
  • Provide a password and remember it (This can be the same password as for the the whole store)
  • Provide an alias – best the name of your domain

  • You should see the following:

  • Right click the key pair you have create and select ‘Generate Certification Request’

  • Portecle will generate file ‘XYZ.csr‘ for you.
  • Provide the contents of this file to the SSL provider of your choice (see a brief comparison here – I’ve had good experiences with RapidSSL certificates from GoGetSSL).
  • Your SSL provider should supply you with an SSL certificate. This file should end with ‘.crt‘. Download it.
  • Go back to Portecle and right click your key pair again. Select ‘Import CA Reply’.

  • Import the .crt file you got from your SSL provider.
  • If this does not work, first proceed to import the certificates as listed in the next steps, then try again to import the CA Reply.
  • You can import the ROOT certificate of your SSL provider just in case.
  • Also, your SSL provider will supply you with an intermediate and server certificate. You can import these into your keystore as well.
  • Note that when importing the ROOT certificate of your provider, you might get a warning that no trust chain can be established to the certificate. However, when importing the intermediate and server certificates AFTER importing the root certificate, there should be no warning that no chain can be established.
  • Your keystore should look something like this now:

  • Now go to File / Save Keystore
  • Provide the same password you used before.

Now you can use the created key store in Java servers. For an easy way how to use a keystore with Java, check out step 7 in this post.

Getting Started with Meteor.js (Review)


The book Getting Started with Meteor.js JavaScript Framework by Isaac Strack provides a valuable resource to complement the online documentation for the Meteor.js framework. It features plenty of examples and integrates these into one comprehensive scenario; the implementation of a simple lending library. I would have loved to see some more background and advice on how to build large applications with Meteor and some patterns/solutions for common architectural level problems. But, hey, it’s not like there are hundreds of books out there on Meteor.js so these issues might be something for a sequel!


Meteor.js is an emerging JavaScript framework which aims to simplify communication between application servers and JavaScript clients.

Traditionally, we would deploy some form of RESTful service (or SOAP, for the brave) on the server, which is then consumed through AJAX calls from the JavaScript application. Thus, we end up with two idiosyncratic applications: one for the server and one for the client. Often, these two applications would be implemented using different languages; such as Java or C# on the server-side and, naturally, JavaScript for the client side. As a more recent development, node.js is employed to remedy some of the difficulties arising from this arrangement by allowing both the client and the server to be implemented using one language: JavaScript.

Meteor, building on node.js, goes one step further than the common node.js application and allows JavaScript clients direct access to the application database (a MongoDB database, to be precise). Since JavaScript clients should sensibly not be given full authorization to the database, privileged database operations can be performed by JavaScript scripts applications running on the server. Meteor allows to write both client-code and privileged code in one JavaScript file and takes care that only appropriate code is available to the client.

Meteor is thus quite different to the traditional way of building web applications. As such, some problems which we came used to expect cease to be of relevance, while new and different problems might come to the fore. Thus, when reading the book Getting Started with Meteor.js JavaScript Framework by Isaac Strack, my prime interest was in the following two points:

  • Does the book serve as useful manual for navigating the basics of Meteor.js? and
  • Does the book point to possible medium-term to long-term problems and provides pattern/solutions of dealing with these.

Navigating the Basics of Meteor.js

The book definitely gives a good foundation to start using Meteor.js and overcoming various roadblocks one might encounter. This ranges from the very basics covered in chapter 1 ‘Setup and Installation’ (note, the book covers only setup and installation for Linux and Mac and not the new deployment for windows) to more elaborate questions discussed for instance in chapters 4 ‘Templates’ and chapter 7 ‘Packaging and Deploying’. Everything is explained clearly and concisely with lots of practical advice, links pointing to further resources, plenty of code examples and additional background explanations.

I especially like that the chapters 2 to 7 explore an exhaustive example of building a Meteor application, a simple lending library:

Using Meteor, we’re going to build a Lending Library. We’ll keep track of all our stuff, and who we lent it to, so that the next time we can’t remember where we put our linear compression wrench, we can simply look up who we last lent it to, and go get it back from them.

This application is brought up to a fairly sophisticated level, adding database persistence and support for multiple users including login screen etc!

Problems, Patterns and Solutions

The book does a very good job at explaining the motivation and benefits of the Meteor platform in chapter 3 accordingly named ‘Why Meteor Rocks!’. This chapter in particular explores the benefits of the MVVM (Model View View-Model) enabled by Meteor. However, there is little information on what kind of medium-term or long-term issues might arise in developing an application for Meteor.js and how these could be mitigated, for instance in form of design pattern. But, then, the very title of the book focusses on ‘Getting Started with Meteor.js’ so I guess it’s fair enough if these more abstract and complex issues are omitted.


See above!

Disclaimer: I’ve created Appjangle, which some might say is similar to Meteor.js. However, I would disagree, since Appjangle is more of a cloud platform and focusses on supporting Java and JavaScript, while Meteor is a more of a framework with a strong focus on JavaScript. In any case, I think Meteor is great and thus consider my judgment unblemished J. Further, thanks to Packt Publishing for a free copy of this book!