How to prevent Jedis wrapping your exceptions

When you integrate Jedis in to your application, and if you are using Spring 3.2.x with it then you will realize some of your exception are wrapped by Jedis and you get:

Caused by: org.springframework.data.redis.RedisSystemException: Unknown jedis exception; nested exception is ...

Nested exception would be your actual exception. When your exception is wrapped with another exception you might not be able to catch the correct exception. And also it simply confuses everyone.

Spring DAO looks for beans with interface PersistenceExceptionTranslator and JedisConnectionFactory implements this indirectly via RedisConnectionFactory. So suddenly you have a new Exception translator and JedisConnectionFactory is more aggressive to wrap exceptions.

So this is a problem, how can you avoid. I think later versions of Spring might not have this problem and it might be configurable for Exception translators. But for Spring 3.2.x we seem to be unlucky, but hey, there’s this piece of code:


// Let it throw raw if the type of the exception is on the throws clause of the method.
if (!this.alwaysTranslate && ReflectionUtils.declaresException(mi.getMethod(), ex.getClass())) {
throw ex;
}
else {
throw DataAccessUtils.translateIfNecessary(ex, this.persistenceExceptionTranslator);
}

So ReflectionUtils.declaresException(mi.getMethod(), ex.getClass()) is the key.

If you explicitly declare your exception on whichever method throws it, you will get that exception without being wrapped.

Apache X-Forwarded-For on AWS and ELB

Recently I spent quite some time troubleshooting why our application is unable to get X-Forwarded-For header.  There is Amazon Elastic Load Balancer at the front and then Apache and then application runs on Tomcat and we use Spring MVC. So one of these might have been suppressing this. I did logging for each one of them. I made sure ELB sends the header; then checked if Spring environment can receive and found out it does not. Then I checked Tomcat and found out it does not receive it either. Then checked if Apache receives and yes found out it receives it. I made sure it does not send the header with logging.

Use variable: %{X-Forwarded-For}i to log incoming header

Use variable: %{X-Forwarded-For}o to log outgoing header

So Apache eats my header. I don’t why but I know how to prevent it:

Put this into your config: http.conf

Header echo X-Forwarded-For

Solution to JAR dependency conflict problem with Maven

JAR Hell is a term to describe the situation. You can’t simply use different version of JARs in same JVM with traditional ways. OSGi is the ultimate solution. JSR 277 was going to be another solution but apparently it is put on hold.

jar_hell

 

Imagine the above scenario. In this case there will be conflict and nondeterministically either libraryA or libraryB won’t work. Because java classloader will pick up only one of the libraryX jar.

And that’s a problem.

So the simplest solution is to embed older version of libraryX into libraryA and rename it’s packages. And this is how it looks like:

jar_heaven

 

So now libraryA does not depend on an external libraryX but instead it uses all that classes from embedded classes. And so imports instead of:

import com.foo.bar

must be:

import embedded.com.foo.bar

So here is how you can do this with Maven easily: