Jboss using wrong classloader on redeploy

[digitalwarrior]

I'm using jboss 3.0.4/Tomcat 4.1.12.

When I deploy a war file, run my application, then redeploy (even if no changes are made); JBoss uses the previous classloader. I put the following code in my struts Action class:

System.out.println("instance ClassLoader: " + userObj.getClass().getClassLoader());
System.out.println("Object ClassLoader: " + User.class.getClassLoader());

I get the following output:

2003-03-27 12:05:19,901 INFO [STDOUT] instance ClassLoader: org.jboss.mx.loading.UnifiedClassLoader3@3d511e{ url=file:/C:/jboss-3.0.4_tomcat-4.1.12/server/default/tmp/deploy/server/default/deploy/ossweb.war/103.ossweb.war }
2003-03-27 12:05:19,901 INFO [STDOUT] Object ClassLoader: org.jboss.mx.loading.UnifiedClassLoader3@3d511e{url=file:/C:/jboss-3.0.4_tomcat-4.1.12/server/default/tmp/deploy/server/default/deploy/ossweb.war/102.ossweb.war }

The classloader for the instance (set in the session previously) is the current class loader and the Object is the previous classloader. Also, the Action class running after redeploy is the previous Action class as well.
I can deploy, put in a print statement and redeploy and the statement does not print out.

What causes this to happen?
Is Tomcat still holding on to the classes in cache?
Is JBoss not redeploying correctly?
Is something wrong with garbace collection?

I have been looking for a solution to this for 2 months now. Any help would be greatly appreciated.

Thanks in advance.........

[jurel]

I'm have the exact same problem on jboss 3.0.6/Tomcat 4.1.18.

I actually gave up on this two months ago. A redeploy is
a jboss restart for me,

I suspect struts (using v 1.0) has something to do with it
because it was causing weird classloading behaviour with
jboss 2.4.x, too.

I tried this procedure:
1. manually undeploy ear.
2. delete unpacked ear from tmp
3. deploy ear again
Result: nothing, somehow a class is still found in the VM from the previous deployment...

Still looking for clues...
I'm monitoring jboss-user as well so I'll pick up any posts there. Just seems that the list is still busier than the forums...
Thanks

[digitalwarrior]

You mentioned in your procedures that you
"delete unpacked ear from tmp". When I redeploy my application, the app server tries to delete the previous tmp file and I get the following message in the server.log file:

could not delete directory file:/C:/jboss-3.0.4_tomcat-4.1.12/server/default/tmp/deploy/server/default/deploy/ossweb.war/104.ossweb.war restart will delete it.

Also, If I do as you mentioned, delete my application manually so it will undeploy (log file still gives the same message) and then try to delete the tmp file manually too, I get the following message in a Windows dialog:

Cannot delete 104.ossweb: There has been a sharing violation. The source or destination file may be in use.

The VM apparently has it locked for some reason.

I've also read posts that mention using jdk 1.4.1 becuase they have better classloaders and such, but that produces no different results.

Please notify me of any progress you make on this topic.

Thanks.......

[digitalwarrior]

I solved my own problem after 2 months of looking.
Struts is the issue.

I could not get this error to occur when using straight Servlets, so it made me put my focus on struts. i'm currently using Struts 1.0.2.

I downloaded the RC1 of Struts 1.1 and ran my same code using it and this problem did not happen. Hot deploy is now working.

JBoss and/or Tomcat were not the issue.

[chmurny]

I am not sure if you really solved your problem. I have a similar problem with JBoss 3.1.2. The only difference is that the class which is not reloaded correctly is my own extension of one of the Log4j classes. The behavior is the same as you have described in your first message opening this thread. I was experimenting, before I found this discussion - my trace statements are very similar to those in your first message.