5Apr/131

Synced files seem corrupted after upgrade to owncloud 5 version

I just upgraded my owncloud community version from 4.5.7-1 to 5.0.3 with the effect, that I can't read any of my files in the sync folder anymore! All seem to be corrupted. If you have the same problem, continue reading and find out how to solve it. Continue reading...

2Feb/1321

Multipage tiff example for download – test image file

Irfanview LogoRecently I was coding some functionality that was dealing with multipage tiff images. Since I hadn't any multipage pictures on my computer, I thought it shouldn't be too difficult to find some sample files to test with.

So I started my everday search in google: Multipage tiff example, multipage tiff file sample, multipage tif download etc. Nothing. Mostly results about programs that can handle multipage tiffs. Yay! Also google image search left me out in the rain :(. Screenshots of programs that can handle multipage tiffs. Yay, again! Continue reading ...

12Jul/120

Oracle still treats empty string as null

It is really a joke that Oracle still treats empty (zero length) strings as null, even in the year 2012! Recently I came (again) across this fact when we were adding support for Oracle 11g in our application.

I was shocked that this is still an issue. Although they may had their reasons in the past, this is really annoying nowadays. I can't understand why they didn't make a cut a some point, made the default SQL92 compliant and added an option for the legacy systems. If you don't know what I'm talking about:

When you have an Entity that has a String attribute, put an empty String ("") into it and persist it. When you read it back this String attribute is now null instead of ""! This leads to unfunny side-effects especially when you're already supporting other databases like MySQL, MSSQL or PostgreSQL where this isn't an issue. Be prepared to re-check queries, required attributes and JSF pages.

How are you handling the situation? Is there a new option I'm probably not aware of?

9Jul/120

CDI BeforeShutdown Event not fired

Ever wondered why the JEE6 CDI Event BeforeShutdown isn't fired when the container shuts down as described in its javadoc?

Well, this is because it's one of the container lifecycle events that are not accessible for normal CDI managed beans. To get access to these special events, your implementation has to be an CDI Extension.

First, implement the Extension interface:

package org.nightprogrammer.examples.cdi;
 
import javax.enterprise.event.Observes;
import javax.enterprise.inject.spi.BeforeShutdown;
import javax.enterprise.inject.spi.Extension;
 
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
 
public class BeforeShutdownTest implements Extension {
 
	private static final Logger log = LoggerFactory.getLogger(BeforeShutdownTest.class);
 
	public void onShutdown(@Observes BeforeShutdown beforeShutdownEvent) {
		log.debug("shutdown event received!");
	}
}

Second, create a META-INF/services/javax.enterprise.inject.spi.Extension file containing the full qualified classname of your Extension:

org.nightprogrammer.examples.cdi.BeforeShutdownTest

That's it! Now you receive the Event as soon as the container goes down. Would be great if the javadoc would mention that directly in the BeforeShutdown Event though. That would have saved me an hour of research :(.

What do you use for cleaning up resources before a container shuts down?

(Besides contextDestroyed() for webapps and addShutdownHook() for JavaSE applications.)

Tagged as: CDI, Events No Comments
16Apr/120

base64 encode and decode using JDK

Ever asked yourself why the JDK isn't shipped with a builtin base64 encoder/decoder? Well, since JDK 6 there is one - although it's quite buried: javax.xml.bind.DatatypeConverter.

Usage is quite simple:

// encode byte[] to base64 String
String myBase64String = DatatypeConverter.printBase64Binary(myByteData);
// decode base64 String to byte[]
byte[] myByteData = DatatypeConverter.parseBase64Binary(myBase64String);

So no need to add a thirdparty library just for decoding/encoding base64 anymore.

Tagged as: base64, jdk No Comments
15Apr/120

IllegalAccessError, packages and classloaders

Ever wondered why you get an IllegalAccessError when invoking protected/package-private methods on class B from class A although both classes are in the same package?

Well it mostly happens only at runtime when two different classloaders loading the classes. classloader A loads class A, classloader B loads class B. Since the JVM spec, paragraph 5.3 mandates

At runtime, a class or interface is determined not by its name alone, but by a pair: its binary name (§4.2.1) and its defining class loader. Each such class or interface belongs to a single runtime package. The runtime package of a class or interface is determined by the package name and defining class loader of the class or interface.

the package from class A is the same as class B at compile time, but NOT at runtime since it was loaded by different classloaders! To get to the root cause, you have to check why your classes are loaded by different classloaders. For example I came across that problem when using JBoss 7 the first time.

15Apr/122

JBoss 7.1 and java.lang.IllegalAccessError invoking private methods

At my company we're starting to use JBoss 7.1 and came across a problem with its new classloading behavior. We're deploying an EAR with the following structure:

  • EAR
    • lib
      • common.jar
    • ejb.jar

In common.jar are classes included, that have a package-private constructor that should only be used within ejb.jar's factory. For this the factory and the specific classes are located in the same package, but in different jar's. So a client can only use the public constructor of the classes whereas the ejb.jar can invoke the internal contructor not visible to the client.

With JBoss 5.1.0 this worked without a problem. But when we tried the same with JBoss 7.1, we encountered the following Error:

Caused by: java.lang.IllegalAccessError: tried to access method CommonClass.<init>()V from class FactoryClass

This is due to the fact that with JBoss 7 each jar is loaded by a separate classloader. We tried the suggested workaround using the jboss-deployment-structure.xml mentioned in a similar JIRA ticket, but always ended up in two separate classloaders for the jar's.

Since it is a limitation of the underyling JVM and not JBoss 7 we simply added the factory to the common.jar and created a common-client.jar via maven assembly where the factory is excluded. Not nice, but helped us to go on.

14Apr/121

Hibernate GenerationType.AUTO dialect overview

When using Hibernate it quickly comes to the point, where you have to decide how your @Id attribute of your entity should be generated. JPA offers four possible options

  • IDENTITY
  • SEQUENCE
  • TABLE
  • AUTO

For a description of these see the Javadoc of GenerationType.

If you have decided to take IDENTITY or SEQUENCE in the past, this can be a problem when supporting new databases in the future. Sadly, most of the databases don't support both GenerationTypes. That is a bummer, because you have to decide early during development which GenerationType to choose. No matter which you've chosen, it's the wrong one if it's not TABLE or AUTO :).

If you now think, simply changing the GenerationType to AUTO fixes the problem, you can get into serious trouble! Continue reading ...