ClassCastException on redeploy

[Tyoma Sakurakoji]

Hi!

I have a really wierd problem that I still can't solve, even after googling for about 6 hours =(

I've made a simple test servlet that seems to work fine, I'm using JPA that links to MySQL and it also works perfectly. The problem arise after redeploying application to the Tomcat. Actually it works fine the first time I start server and access servlet through browser. But if I change something in my code (even if I add something simple like System.out) when I redeploy the application Tomcat gives me a ClassCastException:

java.lang.ClassCastException: com.mycompany.jpatest.Person cannot be cast to com.mycompany.jpatest.Person
	com.keitaitoys.jpatest.JPAServlet.handleRequest(JPAServlet.java:96)
	com.keitaitoys.jpatest.JPAServlet.doGet(JPAServlet.java:71)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

It can't cast class com.mycompany.jpatest.Person to itself =)))

Here is the code that gives me an error (to be exact it's the for loop at line 7):

// Read the existing entries
Query query = em.createQuery("select e from Person e");
List<Person> list = query.getResultList();

out.println("<table border=\"5\">");

for(Person person : list) {
        	
	out.println("<tr>");
	out.println("<td>");
	out.println(person.getFirstName());
	out.println("</td>");
	out.println("</tr>");
}

out.println("</table>");

After some debugging I find that after redeploying application Person class has the same hash. That means I think that it's still exists in the memory since the first server start/servlet access. It is loaded by classloader and still hangs there even after I deploy a new version of my class. How can I force Tomcat to reload all this classes to get a new version?

It works fine if a restart Tomcat, but this piss me off to restart server every time I want to change something in my code =( Any suggestions?

Thanks!

[Tim Holloway]

A persistent object should have the same hash. In fact, in EJB1 and 2, it was a requirement. That's how the container located EJBs so that it didn't accidentally make duplicate objects and get them all muddled. I think you're referring to the object ID, however, and while it's statistically possible for the object to get assigned the same internal ID on every run, it's not that likely.

On the other hand, 2 classes are not the same class if they are loaded by different classpath handlers, and that's not as easy a problem to diagnose.

Most likely, at least part of the old version of the app didn't undeploy and it's still running.

[Tyoma Sakurakoji]

Tim Holloway wrote:A persistent object should have the same hash. In fact, in EJB1 and 2, it was a requirement. That's how the container located EJBs so that it didn't accidentally make duplicate objects and get them all muddled. I think you're referring to the object ID, however, and while it's statistically possible for the object to get assigned the same internal ID on every run, it's not that likely.

On the other hand, 2 classes are not the same class if they are loaded by different classpath handlers, and that's not as easy a problem to diagnose.

Most likely, at least part of the old version of the app didn't undeploy and it's still running.

Thanks for your answer!

I think the problem is lies within the second reason. Actually, Tomcat do reload all the classes on deploy, at least Servlet classes are reloaded sucessfully, but any atempts to access JPA related classes gives me this exception. I believe that JPA use it's own class loaders that don't hook up to the Tomcat's parent classloader chain so Tomcat is unable to manage it...

Right now, I've ended up just to deploy application with following server restart (just make sure war files is not unwrapped, otherwise you need to delete project folder also). Thanks to Eclipse you can make restart in one button and it restarts really quick (1-2 sec) so it's not a huge problem right now. Anyway if someone would find any solution for this, please share with us.

Thanks!