How to fix org.hibernate.MappingException: Unknown entity Exception in Java

If you have used Hibernate with JPA and using annotation to declare your entity bean then you might have seen this confusing error called "org.hibernate.MappingException: Unknown entity". This error message is so misleading that you could easily lose anywhere between few minutes to few hours looking at wrong places. I was using Spring 3 and Hibernate 3.6 when I got this error,which occurs when addEntity() method was executed. I checked everything, from Spring configuration file applicationContext.xml, Hibernate config file, my Entity class and DAO class to see whether my Entity class is annotated or not, but I was still getting this error message. After some goggling I eventually find that, it was an incorrect import which was causing this error. Both hibernate and JPA has @Entity annotation and some how Eclipse was automatically importing org.hibernate.annotations.Entity instead of javax.persistence.Entity annotation. Once I fixed this import issue, everything went smooth. Unfortunately, this error is not easy to spot, the org.hibernate.annotations.Entity import seemed completely appropriate to many programmers. For a newbie Java or hibernate developer it�s really hard to understand which Entity annotation to use, shouldn't be in org.hibernate.annotations.Entity, but instead it's javax.persistence.Entity. By the way, if you are using auto-complete functionality of Eclipse IDE, then you can blame it them, alternatively you can configure your preferred import in Eclipse.

Read more �

Dealing with org.hibernate.LazyInitializationException: could not initialize proxy - no Session in Hibernate Java

If you are working in Hibernate framework, then you know that one of the key feature of Hibernate is "lazy initialization", which allows framework to lazily initialize dependencies, relationship or association lazily from database on need basis. For example, if you are dealing with User object, which has relationship with Permission object like one user can have multiple permissions, then Hibernate may choose not to initialize the collection which holds all permissions at the time it initialized User object and instead returns a proxy object. At this point, if you close your session and letter tries to access an attribute from Permission object, you will get "org.hibernate.LazyInitializationException: could not initialize proxy - no Session in Hibernate". Why this error comes, because hibernate needs to go database to initialize the proxy object, and connection is already closed. If you remember, what we discussed in difference between get vs load in hibernate that Proxy object is only initialized in Hibernate if you access any attribute other than id itself, that's why you would only see LazyInitializationException if you try to access an attribute other than id. In this article, we will see different scenarios on which you could possibly get "org.hibernate.LazyInitializationException: could not initialize proxy - no Session in Hibernate" and how to solve them appropriately. I have tried to explain reasons which caused the error, and explained the solution as why it will work, but if you still face issues, then feel free to post it here. By the way, good understanding of lazy initialization is also a good Hibernate interview question, so this not only help you to solve this error but also to do well during interviews.

Read more �

Hibernate NullPointerException due to Space in HQL named queries

If you are using Hibernate for implementing persistence layer in Java and JEE application from couple of years then you would have seen this notorious NullPointerException while executing HQL named queries, Exception in thread �main� java.lang.NullPointerException at org.hibernate.hql.ast.ParameterTranslationsImpl .getNamedParameterExpectedType (ParameterTranslationsImpl.java:63). Hibernate has some poor logging in case of Exception, which has caused me hours to debug a simple problem. By looking at NullPointerException below (look full stacktrace below), I had no clue that it's coming because of a missing space on HQL (Hibernate Query language) query. You can also take a look if you can figure this out :

Read more �

Why Catching Throwable or Error is bad?

We often hear advice that catching Throwable or Error is bad practice and Java developer should avoid catching these, but have you thought Why? If language allows you to catch anything which is instance of java.lang.Throwable, then what is the problem of catching them or their subclass java.lang.Error? If they are bad, shouldn't Java itself has prohibited them from catching? Well this all looks good on theory, but not in real world programming. As I said before in Java Exception best practices post, Ideally you should never catch Throwable or in particular Error. There are several reasons why catching instance of java.lang.Throwable is bad idea, because in order to catch them you have to declare at your method signature e.g. public void doSomething() throws Throwable. When you do this, no body knows what kind of Error this method is going to throw, and until you know what is the problem, how can you resolve that. Main purpose of providing Exception handling mechanism is to handle error situation properly, but you can't a provide a solution which can solve all problems. That's why we have specific Exception classes e.g. FileNotFoundException, IllegalArgumentException, IOException and so on. So if you don't know how to resolve or handle error, there is no point catching Throwable, all it make your code hard to read and comprehend. Remember, each error handling code is driven by business/audit/reporting or quality requirement and catching Throwable just obscure those logics.

Read more �

Fixing java.net.BindException: Cannot assign requested address: JVM_Bind in Tomcat, Jetty

Some of the most dreaded error in Java based client server based application is networking related error, e.g. java.net.BindException: Cannot assign requested address: JVM_Bind. I have faced this issue, while working with web servers like Tomcat, Jetty, and Weblogic before, but yesterday it came again, when one of my colleague faced this issue in Windows. As soon as Java programmers sees java.net.BindException, they come to conclusion that it's issue with two process listening on same port, and often mistook it for Java.net.BindException: Address already in use: JVM_Bind:8080, which is slightly different than this. If you look Java documentation for java.net.BindExcpetion, you will find this "Signals that an error occurred while attempting to bind a socket to a local address and port. Typically, the port is in use, or the requested local address could not be assigned." It's the second part, which is more interesting in case of java.net.BindException: Cannot assign requested address: JVM_Bind.

Read more �

How to fix java.net.SocketException: Too many files open java.io.IOException in Tomcat, Weblogic Server

Not many Java programmers knows that socket connections are treated like files and they use file descriptor, which is a limited resource. Different operating system has different limits on number of file handles they can manage. One of the common reason of java.net.SocketException: Too many files open in Tomcat, Weblogic or any Java application server is, too many clients connecting and disconnecting frequently at very short span of time. Since Socket connection internally use TCP protocol, which says that a socket can remain in TIME_WAIT state for some time, even after they are closed. One of the reason to keep closed socket in TIME_WAIT state is to ensure that delayed packets reached to the corresponding socket. Different operating system has different default time to keep sockets in TIME_WAIT state, in Linux it's 60 seconds, while in Windows is 4 minutes. Remember longer the timeout, longer your closed socket will keep file handle, which increase chances of java.net.SocketException: Too many files open exception. This also means, if you are running Tomcat, Weblogic, Websphere or any other web server in windows machine, you are more prone to this error than Linux based systems e.g. Solaris or Ubuntu. By the way this error is same as java.io.IOException: Too many files open exception, which is throw by code from IO package if you try to open a new FileInputStream or any stream pointing to file resource.

Read more �