Exceptions when reloading Spring related classes about hotswapagent HOT 14 CLOSED

It looks like a bug in the agent. There is a methodCache in ReflectionHelper. This cache key is caclculated as the String:
clazz.getName() + "." + methodName + "(" + Arrays.toString(parameterTypes) + ")"

However, this does not take into count classloader. If you use Spring reloading inside two classloaders (e.g. multiple wars), there might be the ClassCastException. I did not test it, but it looks like reasonable explanation of this error.

Please try this version of the agent with bugfix.

from hotswapagent.

Thanks for the new version.

I tried again and I had the same errors (I think..)

Here you can find the full log from the point the class reloading starts.

from hotswapagent.

Which Spring version do you use?

According to the new error log class ClassPathBeanDefinitionScanner is not type of ClassPathScanningCandidateComponentProvider.

from hotswapagent.

We are using the following:

<spring.version>3.0.3.RELEASE</spring.version>
<spring.security.version>3.0.0.RC1</spring.security.version>
<spring.security.oauth.version>1.0.0.M2</spring.security.oauth.version>
<spring.batch.version>2.1.7.RELEASE</spring.batch.version>
<spring.jta.version>1.1.0</spring.jta.version>
<spring.commons.dbcp.version>1.2.2.osgi</spring.commons.dbcp.version>
<spring.commons.fileupload.version>1.2.0</spring.commons.fileupload.version>
<spring.jstl.version>1.2.0</spring.jstl.version>
<spring.servlet.version>2.5.0</spring.servlet.version>
<spring.roo.annotations.version>1.0.0.M1</spring.roo.annotations.version>
<spring.js.version>2.0.6.RELEASE</spring.js.version>

from hotswapagent.

Hmm, 3.0.3 is tested. I have completely disabled method cache in ReflectionHelper, performance penalty should be minor.

Please try this version and attach full log (including application/container startup).

from hotswapagent.

I tried again with this version.

Things changed a lot. No more exceptions.

But the reload failed with this message in IntelliJ:

5:25:28 PM Hot Swap failed
           jetty-8000-dcevm: hierarchy change not implemented; 
           jetty-8000-dcevm: Operation not supported by VM

Attached full log.

The log until line 6402 HOTSWAP AGENT: 17:27:37.019 is the first try of class reloading.
And from that point until the end of the file is the second try.

From what I see both tries had the exact same results.

from hotswapagent.

Change in class hiearchy is supported only by FULL dcevm versions. If you have the LIGHT version than you get this result.

from hotswapagent.

I am using the full dcevm.

Maybe this functionality is only working on oracle java and not openjdk ?

(see first post for JVM information)

from hotswapagent.

OK. It should work primary on openjdk, but someone reports it works on oracle as well

from hotswapagent.

This is probably related directly to DCEVM. Have you changed the class hierarchy (e.g. remove interface, change superclass, ...)?.

Why are so many files reloaded at once? Do you really change most of files and then hit apply changes or this is after change of one file? Can you try autoHotswap=true setting in hotswap-agent.properites instead?

There are some minor issues in the log file. Which version of Jetty do you use? One of these classes is missing:
contextHandlerClass = loader.loadClass("org.mortbay.jetty.handler.ContextHandler");
resourceClass = loader.loadClass("org.mortbay.resource.Resource");
fileResourceClass = loader.loadClass("org.mortbay.resource.FileResource");
resourceCollectionClass = loader.loadClass("org.mortbay.resource.ResourceCollection");

from hotswapagent.

The only change I made was add a single line of code System.out.println("some text"); inside a method (the usual functionality supported by all "normal" JVMs).
Then pressed compile file, and IntelliJ started compiling all these files.

I believe that so many classes are reloaded because it's a multi-module project supported by Nexus. So when I run jetty, it's picking up the war files from Nexus, unless my local build is newer.
So, most probably, the compiled code in IntelliJ is "older" from the code that's running in Jetty; thus reloading all these classes.
I would have to manually build around 50 modules in order to have the "latest" code compiled in IntelliJ, and run Jetty in "offline" mode, so it will not even try to get anything newer from Nexus (there will be because of the time required to build 50 modules).

I also tried without the hotswap-agent, and all classes reloaded correctly. Although there's no reloading in spring context. But my change was effective (the system out was printed).

Jetty is org.mortbay.jetty:jetty:6.1.25.
I can see all of these 4 classes in the jar file of Jetty that is being used.

I tried to run with autoHotswap=true but the VM that runs Jetty dies when I press recompile in debug mode (I tried 3 times...).
It may be the resources.. I don't have any more ram to give it.

from hotswapagent.

autoHotswap=true is instead of debug mode. Just recompile the file and it should be triggered automatically.

from hotswapagent.

Oh OK. I will try that tomorrow then :)

from hotswapagent.

Please reopen if still valid.

from hotswapagent.