- This topic has 7 replies, 4 voices, and was last updated 11 years, 11 months ago by
.
-
Posts
-
Exploded deployment still broken in 10.6.
This was reported quite a while ago.
The workaround is to run up MyEclipse and forcibly undeploy any exploded projects then exploded deploy again.
you ALSO have to keep an eye on the directory exploded to and watch for spurios files appearing from time to time.
you ALSO find that sometimes, if you are running code, and it seem to have nothing changing, that you expect to have changed, then stop the server, undeploy and re-deploy again.
Spot the trend here!!!
I am using JBoss 7.x (with the new “.dodeploy” deployment facility) but have seen on Tomcat too.
It’s a real shame as Exploded deployment is truly AWESOME.
JEE 6, Maven, JBoss 7.x, Arquillian
Tony,
I’d like to confirm that we are on the same page from our prior discussions. You are using the manual deployment mode with JBoss 7 – the auto deployment should be working just fine, but you had a problem with it automatically redeploying too frequently, correct?
You mention you are using the .dodeploy technique – with this you are supposed to touch the .dodeploy file when you want it to pick up changes; I assume you are doing this already? At this point it should be JBoss reacting and picking up the changes and you should see messages to this effect in the console. Can you tell me what happens in your case exactly?
Note – we have made no changes to the deployment logic in JBoss 7 since 10.0.1, changes that would require us to automatically hit the .dodeploy file we will be looking at making in the MyEclipse 11 stream with an updated deployment architecture (also will allow greater control over what you want to deploy). It may actually be counter productive to have the IDE automatically hit the .dodeploy file on every detected change and could possibly result in the same behavior you see now with the auto-deployment; this is something we need to investigate further. For example, with WebSphere in Blue, we have an enhanced mode which does not push changes to the server immediately, but requires that the user hit the “redeploy” button which would send a “diff” to the server instead of redeploying the entire application. Thoughts?
>>
I’d like to confirm that we are on the same page from our prior discussions.
No ignore previous. Nothing to do with that. Its “fixed”.
>>
You mention you are using the .dodeploy technique – with this you are supposed to touch the .dodeploy file when you want it to pick up changes; I assume you are doing this already? At this point it should be JBoss reacting and picking up the changes and you should see messages to this effect in the console. Can you tell me what happens in your case exactly?
Not relevant and in fact when using exploded deployment WRONG UNLESS you alter a method sig OR want a config file to be picked up… its quicker to terminate server and restart anyhow.
I can generally alter .xhtml pages and method code and just carry on and it takes effect instantly; which is what exploded deployment is about If I hit a method sig then I get the “this is way to hard for em to figure out” from the server and I hit the terminate server button and just restart the server… if you want certain other files to take effect (xxx.messages or some config files) then you also have to stop/restart but NEVER EVER do I touch the .dodeploy file.
>>
Note – we have made no changes to the deployment logic in JBoss 7 since 10.0.1, changes that would require us to automatically hit the .dodeploy file we will be looking at making in the MyEclipse 11 stream with an updated deployment architecture (also will allow greater control over what you want to deploy). It may actually be counter productive to have the IDE automatically hit the .dodeploy file on every detected change and could possibly result in the same behavior you see now with the auto-deployment; this is something we need to investigate further. For example, with WebSphere in Blue, we have an enhanced mode which does not push changes to the server immediately, but requires that the user hit the “redeploy” button which would send a “diff” to the server instead of redeploying the entire application. Thoughts?
Not relevant
—-
Back to the defect:
This was reported quite a while ago.
The workaround is to run up MyEclipse and forcibly undeploy any exploded projects then exploded deploy again. [MyEclipse -> Add and remove project depoloyments…]
you ALSO have to keep an eye on the directory exploded to and watch for spurios files appearing from time to time.
you ALSO find that sometimes, if you are running code, and it seem to have nothing changing, that you expect to have changed, then stop the server, undeploy and re-deploy again. [MyEclipse -> Add and remove project depoloyments…]
Spot the trend here!!!
I am using JBoss 7.x (with the new “.dodeploy” deployment facility) but have seen on Tomcat too.
It’s a real shame as Exploded deployment is truly AWESOME.
JEE 6, Maven, JBoss 7.x, Arquillian
Note:
Exploded deploy a project on Tomcat 7 or Jboss 7 then shut MyEclipse and restart.. now alter a file in myeclipse and save it… check if this file has erronorusly been copied by MyEclipse into the wrong area… it gets put (often) in my case, C:\jboss-as-7.1.1.Final\standalone\deployments directory as opposed to INSIDE the deployed project…. Happy bug hunting…Tony,
1) With JBoss 7, do you have the “use auto-deploy mode” checkbox checked or not? I’m assuming not, please confirm.
2)
This was reported quite a while ago.
The workaround is to run up MyEclipse and forcibly undeploy any exploded projects then exploded deploy again. [MyEclipse -> Add and remove project depoloyments…]
you ALSO have to keep an eye on the directory exploded to and watch for spurios files appearing from time to time.
you ALSO find that sometimes, if you are running code, and it seem to have nothing changing, that you expect to have changed, then stop the server, undeploy and re-deploy again. [MyEclipse -> Add and remove project depoloyments…]
Please point me to the thread where you have originally reported this problem so I have the right context.
The only other issue that we are tracking but haven’t yet fixed is
it gets put (often) in my case, C:\jboss-as-7.1.1.Final\standalone\deployments directory as opposed to INSIDE the deployed project….
– we were unable to reproduce this after spending over a day trying to reproduce. My only explanation is that perhaps there is something specific to your project configuration that is causing the deployment logic to trip and behave in this way. If you could send us your .project, .classpath, .mymetadata file along with all files in your .settings folder and the web.xml file, that would help. Can you please ZIP and email these to support@genuitec.com with a link to this thread?
Also, you originally reported this problem with Tomcat 7, so I take it that it happens with both Tomcat 7 and JBoss 7. If this project is a Maven project, please include your pom.xml too. If you do have non-Maven projects, have you noticed this problem with them too?Tony,
This issue has now been fixed in release 10.7. You can use the Configuration Center to update to 10.7. Alternatively download the MyEclipse or MyEclipse Blue installer from our download page.
Thanks for reporting the issue and sorry for the inconvenience.
