And again, another quick reminder for myself: How to enter/send Ctrl+Alt+Del with VMware Fusion without using the menubar:
On an external keyboard:
Ctrl+Alt+Del (⌃+⌥+⌦)
On an internal MacBook keyboard:
Fn+Ctrl+Alt+Del (Fn+⌃+⌥+⌦)
The net.sf.ehcache.transaction.TransactionTimeoutException is one of those unchecked RuntimeExceptions you should take care of if you use ehcache. If this exceptions occurs you must explicitly rollback the ongoing transaction, otherwise all further requests to start an ehcache transaction from within the current thread will fail with another net.sf.ehcache.transaction.TransactionException as the cache is in an inconsistent state.
I do it like so:
final TransactionController transactionController = cacheManager.getTransactionController(); try { transactionController.begin(); // Do stuff transactionController.commit(); } catch(TransactionTimeoutException e) { // Rollback transaction because cache will be invalid from this point transactionController.rollback(); // Rethrow or handle e in some way } |
You don’t need JConsole or similar for just displaying the approximate uptime of your application respectively your Java Virtual Machine:
import java.lang.management.ManagementFactory; public class Demo { public static void main(String... args) { final long uptime = ManagementFactory.getRuntimeMXBean().getUptime(); System.out.println(String.format("Up for %dms", uptime)); } } |
If you use Joda-Time (and you should if you have anything to do with date/datetime processing), you can format it nicely like so:
import java.lang.management.ManagementFactory; import java.text.MessageFormat; import org.joda.time.Period; import org.joda.time.PeriodType; import org.joda.time.format.PeriodFormatter; import org.joda.time.format.PeriodFormatterBuilder; public class Demo { public static void main(String... args) { final Period vmUptime = new Period(ManagementFactory.getRuntimeMXBean().getUptime()).normalizedStandard(PeriodType.yearDayTime()); final PeriodFormatter pf = new PeriodFormatterBuilder() .printZeroAlways() .appendDays().appendLiteral(MessageFormat.format("{0,choice,0# days, |1# day, |2# days, }", vmUptime.getDays())) .minimumPrintedDigits(2) .appendHours().appendLiteral(":").appendMinutes() .toFormatter(); System.out.println(String.format("Up for %s", pf.print(vmUptime))); } } |
You also have a nice example of the often unknown MessageFormat.
Javas ImageIO works… well, most of the time. It contains some unfixed, jpeg related bugs, but it works.
It may contain some dangers when used in a webbased application for generation large images on the fly.
Most problems are related to ImageIOs filed based caching and not flushing buffers when an IOException in an underlying stream occurs.
First, the javax.imageio.ImageReader. It caches some data in files. It is essential to dispose the reader and the underlying ImageInputStream after use if it’s not needed anymore like so:
if(imageReader.getInput() != null && imageReader.getInput() instanceof ImageInputStream) ((ImageInputStream)imageReader.getInput()).close(); imageReader.dispose(); |
If it isn’t closed and disposed, the temporary cache files are either deleted not at all or maybe at the next garbage collection. I was able to bring down a VM by “java.io.FileNotFoundException: (Too many open files)” several times because i didn’t close a reader in a loop. Even the classloader wasn’t able to load any new classes after the ImageReader going mad on the file handle.
The other side is the javax.imageio.ImageWriter. There is an issue mentioned in the Tomcat Wiki.
I used the ImageWriter to dynamically create large images. I directly passed the javax.servlet.ServletOutputStream to the ImageWriter. If the generation of images takes long enough, there’s a good chance that the client aborts the request and the ServletOutputStream gets flushed right when the ImageWriter is writing to it. I didn’t have the exceptions mentioned in the wiki but my VM crashed. Great. I guess it had something to do with the native org.apache.coyote.ajp.AjpAprProtocol Ajp Apr connector i use, but that’s just guessing.
I solved this problem by using a temporary file and its related outputstream which i then stream like described here. This solution is not only faster but i also can catch any exception related to an aborting client.
Also take care to dispose the write as well like so:
try { imageWriter.setOutput(out); imageWriter.write(null, new IIOImage(image, null, null), iwp); out.flush(); } catch(IOException e) { imageWriter.abort(); throw e; } finally { try { out.close(); } catch(Exception inner) { } imageWriter.dispose(); } |
This took me several hours to figure out… I hope someone finds this post useful.
I think that almost no website today can do without JavaScript. There are some incredible good JavaScript libraries like jQuery for which an enormous mass of plugins and extensions exits.
The downside of this is, that for example the JavaScript code of my daily picture project Daily Fratze is bigger than the whole startpage of my first “homepage” was.
With every problem there is a solution, namely JavaScript compressors and minifier. Those tools can compress the code by removing superfluous whitespaces, renaming variables and functions or even by optimizing the code.
So far i have used the YUI compressor maven mojo in my Spring based projects. This is a build time solution that compresses JavaScript and CSS files when creating a war file.
For me it had several disadvantages: I don’t see the effect of compressing when i develop my application and it could not concatenate multiple script files.
The later is important because every additional request a browser makes slows down the loading of a webpage. And manual hacking all JavaScript into one file? No way…
wro4j to the rescue:
Free and Open Source Java project which brings together almost all the modern web tools: JsHint, CssLint, JsMin, Google Closure compressor, YUI Compressor, UglifyJs, Dojo Shrinksafe, Css Variables Support, JSON Compression, Less, Sass, CoffeeScript and much more. In the same time, the aim is to keep it as simple as possible and as extensible as possible in order to be easily adapted to application specific needs.
My goal was to integrate wro4j with Spring and ehcache with a minimum number of additional configuration files.
If you’re interested in some of my ideas, read on: