On Jun 21, 2011, at 2:23 AM, Mattias Jiderhamn wrote:
> I'm so glad you posted this Jeff, since the same thing happened to us
> yesterday. I still don't know how, but finally we realized that somehow
> the same JSP page was compiled both as case sensitive and all lower case
> (_myJsp__jsp.java and _myjsp__jsp.java).
> What really threw us off though, was the fact that when we tried to
> deploy this "broken" WAR, Resin in some mysterious way managed to deploy
> an old version of that WAR. We deleted the WAR, we deleted the exploded
> WAR archive, we restarted Resin. Versioning was and has always been off.
> But magically an old no-longer-existing WAR was deployed in place of the
> (broken) one we tried to deploy. I don't remember for sure, but possibly
> the magic stopped when we deleted [server.root]/resin-data/default/.git
> (though I couldn't find any file in there enough to match the WAR. By far.)
> Possibly the fact that I managed to remote deploy that same WAR for the
> first time earlier yesterday has something to do with this? I might wait
> a while until I dare to try remote deploy again...
> I saw that the broken WAR problem should be fixed - or handled better -
> in 4.0.19. Haven't tried it.
> However I would still like to understand how Resin could deploy a WAR
> that no longer existed? Is there anyway to turn it off? I sure hope that
> this never ever happens in production (knock on wood!), but what should
> we do if it does happens again?
What you're describing is exactly the effects of a remote deployment.
Doing a remote deploy essentially puts your war into a git distributed version
control system. (In resin-data/*/.git) So even if there is no .war in the
webapps directory, Resin will deploy it there upon startup. Once you "deploy"
an application, deleting the .war does nothing. You must undeploy it remove
it, or redeploy a new version to update.
Unfortunately until version 4.0.19, there was no undeploy button in
/resin-admin, only a deploy. So to undeploy cleanly you had to use the
command-line interface, which is somewhat less convenient since it requires
RemoteAdminService and some authentication setup.
We realize this behavior is unexpected/surprising when not understood, and are
discussing ways to improve usability.
Paul Cowan, Software Engineer
resin-interest mailing list