- This topic has 4 replies, 2 voices, and was last updated 21 years ago by
.
-
Posts
-
It appears to me that the deployment method for JBoss features a bug. My ear-project (one ejb, one web) could not be deployed anymore. So far so sad. But what really drive me a bit crazy is, the deployment method still looks me in my face and claiming everything is allright. Even in the packed mode it does not deploy anything nor creating anything of a file. But redeployment fails and removing also. The only thing happening, the deployment method says, I should stop jboss and delete the ear file (which file?!). After creating a empty file named the same like the ear, the deployment function gets happy and removes this.
But hey, why does this function still claims, deployment is alright. Nothing is done, nothing is written to disk… . I think the deployment function should check if it done the job and promt a info-message if something went wrong.
And if possible it should give me any hint, why the deployment fails… I dont want to recreate and reconfigure the project for the fourth time again. I dont know why, but the deployment screws up over and over again.
But please correct the deployment method. Creating an empty-file when removing / redeployment fails, isn’t a desired solution to me.
Thanks
For the files:
This time the deployment failed cause of adding a non-referenced library to the class-path of MANIFEST.FM of the web and ejb subprojects. Of cause I didn’t got an error message. But I knew what I ‘ve done last time so I could unroll it.
Help me understand how the problem arises. Can you describe the sequence of actions and events that leads to this problem?
For example I am assuming that you are attempting an undeployment or redployment action. If this is the case you may be hitting a file locking problem where the JBoss process locks 1 or more files/dirs of an exploded deployment. This prevents any process from deleting the files/dir. In such cases the only remedy is to stop JBoss and manually remove the remnant file(s) and directory structure. An easy work-around to avoid this problem is to touch the appliction.xml file which will stimulate JBoss into reloading the application without the heavy weight undeploy step.
Send details.
Michael
MyEclipse SupportOk here is how I screw it up this time (did this some other ways too, but doesn’t matter).
First take a EAR (EJB+WEB) and modify (for example) the MANIFEST.FM file and include something unparsable/understandable, or just reference a library not referred to the project. Now add a deployment to your favorite server. The deployment will succed. But looking at JBoss or in the directory, nothing (cause your manifest is wrong i guess).
But luckily the deployment function is still proud of its own work and claims everything is alright. But dont hit the remove button or the redeploy button. The deployment function will notice that nothing is left to delete. “Oh gosh! Dear user you screwed off your deployment stuff. Shut down JBoss and remove it yourself”, the deployment functions says. Ok lets kill JBoss then. But delete? what where, how? Well the function wont know 😉 So lets get back and tell the function to remove the deployment entry. Same again. “Dear user where is your deployment?” – “Uhm well its not there anymore, I’ve done like you said. I shut down JBoss and removed the file (*sure I am lying but the file isn’t there anyway).” – “Well dear user, I am a proud deployment function! Therefore I am not removing the deployment entry until I removed the ear myself. I wasted it so I am gonna remove it!” – Huh?
Now the huddle really starts. Nowing the proudness of the function I created a dummy ear file (empty txt-file renamed to the ear) in a temp-folder. Therefore moving the dummy ear to the deployment director (JBoss is already down). Now back to the deployment function. Hitting remove… No complains. Shaka hail! I did it! I fought the evil deployment function!
Um by correcting the manifest.fm the ear is healed and can be deployed again.
Sorry for the story telling mode but I had talked to long to the evil deployment function, that its almost a real person to me 😉
What I would like to see:
– Removing deployment entries even if the former deployment file does not exist (maybe with a ok/chance dialog).
– If the deployment fails, I would like to see an error message about the why and how (in my case a dialog should apear complaining about the problem within the manifest.fm file.PS: Eclipse 2.1.1, MyEclipse 2.6.2, JDK 1.4.2, JBoss 3.2.2
Nice story telling!
The deployment will succed. But looking at JBoss or in the directory, nothing (cause your manifest is wrong i guess).
If the “proud” deployer is unable to copy files to the auto-deployment folder of the target server you should receive a warning explaining the situations and the deployment is aborted. The internal logic is such that this is an all or nothing operation. Therefore I need you to inspect the Eclipse log and determine if there is an error message associated with this problem.
When MyEclipse starts up the deployer verifies that all of its deployments still exists. That is, it confirms that the root folder or the archive of each deployment exist on their targer servers. If these root resources are not located then the deployment is tagged as invalid and removed from the system. So I would expect that in a case where you have manually deleted or moved a root deployment folder or an archive from the target server, that MyEclipse will resync itself just by shutting it down and then restarting. I can see an improvement by surfacing this resync logic as a user-controlled action to resync all deployments and/or to report known deployment issues.
Lastly, until the Reload feature is available try this when you need to force JBoss to reload an application. From within MyEclipse add or remove a space to the application.xml file in the enterprise project, i.e., touch the file. This will cause the proud deployer to update the deployed resource and signal JBoss to reload your deployed application.
I hope this helps.
Michael
MyEclipse Support
