0

There was a problem with a web service we deployed; users could not log in, and our logs displayed errors and exception stack traces. Dev worked on the problem and provided a new package to deploy.

When I deploy the new package and we try to use it, we are still getting the exact same errors and exception stack traces that we were getting before, right down to the same files/line-numbers in the stack trace. Some of the line numbers don't even point to anything that could cause the error but rather point to whitespace on a line number which used to have the problematic line that caused the error.

Undeploy/redeploy, same thing.

Restart JBoss, same thing, undeploy/redeploy, same thing.

Undeploy, move the file that causes the error to "file.jar.bak" so that it "doesn't exist", then redeploy... deploy fails (good, it should at that point) - now there is an error that it cannot deploy because the file cannot be found. OK, that's good, at least it is paying attention to the fact that I am changing the file. But now move the "file.jar.bak" back to being "file.jar" and redeploy again, and it's back to providing the same errors/line-numbers as the old deployment again instead of the new one!

What is going on??? Perhaps is the old one cached somewhere? What else could cause this.

0

sigh I feel dumb now. After typing up my question, while thinking about it and editing it, something suddenly dawned on me and I fixed it. I'll still post it anyway, and share what my dumb mistake was in case it helps others...

We are in the final stages of a migration from JBoss 5 to a newer version. Newer versions are more strict about how you structure certain directory-structures or files in your "ear" archives. Our jar files used to be at the root of the archive, but to satisfy new stricter guidelines they are supposed to be in a "lib/" directory within the archive instead of just at the root of it.

Well, the lib directory was created, and the jar files were put there - by me, even - but the files were copied, not moved. So there were copies of the jar files in the root, and copies of the jar files in the lib/ directory. We kept overwriting the copy in the root directory, which is why our changes were being ignored, since it was using the correct one in lib/.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.