you can add a servlet context listener that looks for the lock file and nukes it.
alternatively you can use the Start class that comes with wicket quickstart archetype/project that does what mvn jetty:run but with the added benefit of allowing hotswapping, and in that class you can add the code to nuke the lock file. -igor On Thu, May 27, 2010 at 9:57 AM, Jakub Skoczen <skoc...@gmail.com> wrote: > Hi Everyone, > > First of all - this question is not directly concerned with Wicket, > sorry for that. But, I did came across this problem when developing a > small Wicket web app, so I thought someone else here may have had a > similar issue. So here it is: I got tired with the slow > write/compile/deploy process and I switched to using jetty:run (with > scanning interval set to 10s) and incrementally compiling the classes. > Unfortunately, right after jetty detects changes to the compiled class > and tries to redeploy the app I get the following HSQLDB exception: > > java.sql.SQLException: The database is already in use by another > process: org.hsqldb.persist.niolockf...@7c137657[...] is presumably > locked by another process. > > HSQLDB is run using the in-process mode and the following exception is > thrown both when using memory and file backend. It obviously looks > like HSQLDB is not releasing the lock during the auto redeployment, > maybe Jetty is locking up the thread somehow? Anyways, any ideas will > be greatly appreciated. > -- > > Cheers, > Jakub > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
