[ http://issues.apache.org/jira/browse/GERONIMO-2167?page=comments#action_12421485 ] Leonard Wu commented on GERONIMO-2167: --------------------------------------
You know. I had a thought. That webapp actually uses a inbuilt Java database, HSQL. I suspect that the lock isn't released quick enough by the running HSQL while the app was being shutdown. Now that I've tried other webapps, I can confirm that all the other ones deployed and undeployed perfectly. So it would appear that the deploy problem is specific to my unlucky choice of test app. And, I personally have no real reason to choose HSQL over the G internal Derby, either :) so this is no longer a problem for me. Assuming that you are still determined to iron out all kinks in G, please see the newly attached sources for the orginal test app. I've included IntelliJ v5 project files in case you happen to be using that. > deployer.jar not cleaning up properly during redeploy and undeploy > ------------------------------------------------------------------ > > Key: GERONIMO-2167 > URL: http://issues.apache.org/jira/browse/GERONIMO-2167 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment > Affects Versions: 1.1 > Environment: Win32/XP SP1 > Sun JDK 1.5_06 > Reporter: Leonard Wu > Assigned To: Kevan Miller > Fix For: 1.1.1 > > Attachments: dwr-demo.war > > > deployment using deploy.jar doesn't appear to clean up correctly. > first deploy always works. subsequent re-deploy and un-deploy are problematic. > following illustrates the full sequence of events as i had encountered: > ------------------------------------------ > D:\work\SERVER\geronimo-1.1\bin>c:\JDK\jdk1.5.0_06\bin\java.exe -jar > deployer.ja > r --user system --password manager deploy D:/work/SERVER/dwr-demo.war > Deployed littleoldme/dwrdemo/1.1/war @ http://vaio:8080/dwr-demo > D:\work\SERVER\geronimo-1.1\bin>c:\JDK\jdk1.5.0_06\bin\java.exe -jar > deployer.ja > r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war > No ModuleID or TargetModuleID provided. Attempting to guess based > on the content of the archive. > Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war' > Stopped littleoldme/dwrdemo/1.1/war > Unloaded littleoldme/dwrdemo/1.1/war > Uninstalled littleoldme/dwrdemo/1.1/war > Deployed littleoldme/dwrdemo/1.1/war > Started littleoldme/dwrdemo/1.1/war > Redeployed littleoldme/dwrdemo/1.1/war > D:\work\SERVER\geronimo-1.1\bin>c:\JDK\jdk1.5.0_06\bin\java.exe -jar > deployer.ja > r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war > No ModuleID or TargetModuleID provided. Attempting to guess based > on the content of the archive. > Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war' > Stopped littleoldme/dwrdemo/1.1/war > Unloaded littleoldme/dwrdemo/1.1/war > Uninstalled littleoldme/dwrdemo/1.1/war > Error: Operation failed: > org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException: > Configuration already exists: littleoldme/dwrdemo/1.1/war > Configuration already exists: littleoldme/dwrdemo/1.1/war > D:\work\SERVER\geronimo-1.1\bin>c:\JDK\jdk1.5.0_06\bin\java.exe -jar > deployer.ja > r --user system --password manager undeploy littleoldme/dwrdemo/1.1/war > Error: littleoldme/dwrdemo/1.1/war does not appear to be a the name > of a module available on the selected server. Perhaps it has already > been stopped or undeployed? If you're trying to specify a > TargetModuleID, use the syntax TargetName|ModuleName instead. If > you're not sure what's running, try the list-modules command. > ------------------------------------------ > While in this broken state, i'm able to recover by manually removing the > ${geronimo}/repository/littleoldme directory and removing the one line in > ${geronimo}/var/config/config.xml that says > <module load="false" name="littleoldme/dwrdemo/1.1/war"/> > However, this only gets me to a fresh beginning, and then the whole sequence > starts again as I repeat (re/un)deploying. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
