- This topic has 3 replies, 2 voices, and was last updated 19 years, 1 month ago by
.
-
Posts
-
BTW, I’m using 4.0.1GA / have deploy set for exploded, not packaged, and I think set for doing a backup. No dependent projects.
If I deploy, and Tomcat is already started from MyEclipse, the deploy takes 30 seconds then says it failed. I have to exit, stop tomcat, then re-redeploy, then restart tomcat.
Since you (MyEclipse) already know you started tomcat, one option would be for you to stop it, redeploy, the restart it all as a part of the redeploy process.
Ideally, however, a better tact is to keep track that I just changed one little jsp page and you COULD just copy that one simple page unstead of doing a massive change like that to begin with. This is assuming the deploy was exploded not packaged of course.
Either is an improvement.
Originally I saw some blurb about backing up prior to deploy but I’m not seeing that now, so I think maybe that only came up with a previous deploy because there was an existing direction out there. That directory was now gone with the creation of this deploy so there is no longer any mention of a “backup first” option – ignore references to that above.
OK, I’m still learning about MyEclipse and it shows. It appears that if I start the server and then modify a Class or a jsp in MyEclipse it in fact auto-deploys that single change over to the server automatically without any request to deploy. COOL, I didn’t know that. That is a VERY nice way to test/modify/test. Thank you!
I haven’t noticed this in the docs anywhere yet, though I’m sure its probably out there somewhere in the docs, so I’m not sure if this works for all changes possible (Classes, JSPs, configs) or if possibly the config file changes have to be done with a server stop/start.
So, to some degree this isn’t a big deal though to be honest, deploy knowing the state of an internal server startup seems like a no-brainer that if its up, do a stop, deploy, restart instead of TRYING to deploy and hitting failure situations.
I’m still digging but so far this looks pretty darn good …
If I deploy, and Tomcat is already started from MyEclipse, the deploy takes 30 seconds then says it failed. I have to exit, stop tomcat, then re-redeploy, then restart tomcat.
Don’t deploy to a running app server, it will almost certainly have read locks on your JARs and cause deployment to fail.
Since you (MyEclipse) already know you started tomcat, one option would be for you to stop it, redeploy, the restart it all as a part of the redeploy process.
This is not universal, you don’t need to worry about readlocks on Unix/Linux. Windows file system (NTFS) is implemented such that a file cannot change while read locks exist for it, this is not the case for most Unix/Linux file systems.
Ideally, however, a better tact is to keep track that I just changed one little jsp page and you COULD just copy that one simple page unstead of doing a massive change like that to begin with. This is assuming the deploy was exploded not packaged of course.
You just described exactly what happens when you use an exploded deployment. If you have Project > Build automatically turned on, as soon asyou save the file it is built and deployed out to your app server.
OK, I’m still learning about MyEclipse and it shows. It appears that if I start the server and then modify a Class or a jsp in MyEclipse it in fact auto-deploys that single change over to the server automatically without any request to deploy. COOL, I didn’t know that. That is a VERY nice way to test/modify/test. Thank you!
Glad you like it.
I haven’t noticed this in the docs anywhere yet, though I’m sure its probably out there somewhere in the docs, so I’m not sure if this works for all changes possible (Classes, JSPs, configs) or if possibly the config file changes have to be done with a server stop/start.
We copy EVERY file out, but it depends on your app server if it reloads it or not. For example, struts-config.xml files are not reloaded because the main struts servlet was not written to check for changes to that file.
