-
1. Re: proper redeployment under JBoss6?
jaikiran Jun 29, 2011 5:45 AM (in response to alfonz19)martin mucha wrote:
But after switching to JBoss6 I'm facing *very ofter* problem that after redeployment (as described) of new version the old version gets deployed again instead!
Can you explain a bit more? What shows up as old data?
-
2. Re: proper redeployment under JBoss6?
alfonz19 Jun 29, 2011 6:02 AM (in response to jaikiran)ok, no problem.
Actually I do not *know* what is happening, I just observe it as a black box. I happens like this:
I've got running AS with deployed application. I noticed a bug in it and corrected it in sources, rebuild app, deleted old ear from deploy directory of running jboss, moved new build into deploy directory. Apps get deployed, I check whether error is still present, and it is! I'm confused, but also lucky enough that I've run Jboss with arguments
-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
so I just attach debugger and look closely why the correction did not work, AND debugger stops on blank lines, outside of methods, follow the code improperly --> there *must* be inconsistence between running app and source code.
shut down AS,
rm -rf work tmp data log
start AS again, application works as expected.
-
3. Re: proper redeployment under JBoss6?
wdfink Jun 29, 2011 8:13 AM (in response to alfonz19)Do you changed anything other than ear? Can it be possible that you provide an interface jar in the lib directory?
Does it work without deleting tmp directory?
-
4. Re: proper redeployment under JBoss6?
alfonz19 Jun 29, 2011 9:16 AM (in response to wdfink)no, just the ear was modified. Deleted and than other file was moved to that location. Happened many times so I'm absolutery sure that ... I did not intentionaly touch anything else. Of course I cannot grant that OS did not touch some file, but that's I think highly improbable. The OS is linux, if that can cause something (if I remember it correctly, on linux is possible delete file while this file will be available on for processes already having handle to it, which is kind a different from windows where such file won't be allowed for deletion -- but I find this to be also highly improbable as a reason for this behavior)
Ok, next time I saw this problem I'll check whether sole AS restart is sufficient to solve the problem. If it won't help then I check whether deletion of work data log
will save the day.
Btw. thanks for helping me.