Re: Jetty, HSQLDB and automatic scanning
other solution would be to use embedded HSQL, if you want to know how checkout http://code.google.com/p/wicketcool/, generate project using it, and check jdbc.properties in domain module. good luck On Thu, May 27, 2010 at 11:22 PM, Peter Ertl pe...@gmx.org wrote: maybe you should properly shutdown hsqldb in Application#onDestroy() ... Am 27.05.2010 um 19:00 schrieb Igor Vaynberg: 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Best regards, Paul Szulc http://paulszulc.wordpress.com
Re: Jetty, HSQLDB and automatic scanning
On Thu, May 27, 2010 at 7:00 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: you can add a servlet context listener that looks for the lock file and nukes it. I had a similar idea for a while but hoped for a cleaner approach. Anyways after reading through the docs it looks like HSQLDB is using the standard Java lock file that gets released when the JVM exits, hence the issue. Nevertheless, you can force it to remove the lock by issuing SQL SHUTDOWN command to the DB. Now I'm trying to introduce that in some unobtrusive way - I hit the DB via Hibernate - maybe subclassing the DataSource would work. I'll see what I can come up with and report back. 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 -- Cheers, Jakub - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Jetty, HSQLDB and automatic scanning
Well, I'm using an embedded (in-process) HSQL, that's the very reason I get this error. Is wicket-cool addressing this particular issue in some way? On Fri, May 28, 2010 at 9:54 AM, Paul Szulc paul.sz...@gmail.com wrote: other solution would be to use embedded HSQL, if you want to know how checkout http://code.google.com/p/wicketcool/, generate project using it, and check jdbc.properties in domain module. good luck On Thu, May 27, 2010 at 11:22 PM, Peter Ertl pe...@gmx.org wrote: maybe you should properly shutdown hsqldb in Application#onDestroy() ... Am 27.05.2010 um 19:00 schrieb Igor Vaynberg: 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Best regards, Paul Szulc http://paulszulc.wordpress.com -- Cheers, Jakub - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Jetty, HSQLDB and automatic scanning
(sorry if that gotten reposted, I mistakenly used a different email address that may have not been registered with the ML) On Thu, May 27, 2010 at 7:00 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: you can add a servlet context listener that looks for the lock file and nukes it. I had a similar idea for a while but hoped for a cleaner approach. Anyways after reading through the docs it looks like HSQLDB is using the standard Java lock file that gets released when the JVM exits, hence the issue. Nevertheless, you can force it to remove the lock by issuing SQL SHUTDOWN command to the DB. Now I'm trying to introduce that in some unobtrusive way - I hit the DB via Hibernate - maybe subclassing the DataSource would work. I'll see what I can come up with and report back. 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 -- Cheers, Jakub - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Jetty, HSQLDB and automatic scanning
Hmm wicket-cool generates project that uses embedded hsql as database and
uses it for test in all modules (domain, service and webapplication) as well
as for jetty:run deployment.
I do not have problems you are speaking of so you might as well just try it.
Here is what I did:
jdbc.properties file looks like this:
# connection
driver=org.hsqldb.jdbcDriver
changeLogFile=dbchangelogs/db.changelog.xml
url=jdbc:hsqldb:file:hsqldbs/test.db;shutdown=true
datasource.url=jdbc:hsqldb:file:../hsqldbs/test.db;shutdown=true
username=sa
password=
# hibernate and jpa configuration
hibernate.generate_statistics = true
jpa.showSql = true
jpa.database = HSQL
and application context like this:
bean id=dataSource
class=org.springframework.jdbc.datasource.DriverManagerDataSource
p:driverClassName=${driver} p:url=${datasource.url}/
bean id=transactionManager
class=org.springframework.orm.jpa.JpaTransactionManager
p:entityManagerFactory-ref=entityManagerFactory/
bean id=entityManagerFactory
class=org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean
p:dataSource-ref=dataSource
p:jpaVendorAdapter-ref=jpaAdapter
property name=loadTimeWeaver
bean
class=org.springframework.instrument.classloading.InstrumentationLoadTimeWeaver/
/property
property name=persistenceUnitName
value=wctemplatePU/property
/bean
bean id=jpaAdapter
class=org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter
p:database=${jpa.database} p:showSql=${jpa.showSql}/
On Fri, May 28, 2010 at 10:48 AM, Jakub Skoczen ja...@indexdata.dk wrote:
Well, I'm using an embedded (in-process) HSQL, that's the very reason
I get this error. Is wicket-cool addressing this particular issue in
some way?
On Fri, May 28, 2010 at 9:54 AM, Paul Szulc paul.sz...@gmail.com wrote:
other solution would be to use embedded HSQL, if you want to know how
checkout http://code.google.com/p/wicketcool/, generate project using
it,
and check jdbc.properties in domain module.
good luck
On Thu, May 27, 2010 at 11:22 PM, Peter Ertl pe...@gmx.org wrote:
maybe you should properly shutdown hsqldb in Application#onDestroy() ...
Am 27.05.2010 um 19:00 schrieb Igor Vaynberg:
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Best regards,
Paul Szulc
http://paulszulc.wordpress.com
--
Cheers,
Jakub
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Best regards,
Paul Szulc
http://paulszulc.wordpress.com
Re: Jetty, HSQLDB and automatic scanning
maybe you lack of shutdown=true ? shutdown=true shuts when connections are closed On Fri, May 28, 2010 at 10:53 AM, Jakub Skoczen skoc...@gmail.com wrote: (sorry if that gotten reposted, I mistakenly used a different email address that may have not been registered with the ML) On Thu, May 27, 2010 at 7:00 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: you can add a servlet context listener that looks for the lock file and nukes it. I had a similar idea for a while but hoped for a cleaner approach. Anyways after reading through the docs it looks like HSQLDB is using the standard Java lock file that gets released when the JVM exits, hence the issue. Nevertheless, you can force it to remove the lock by issuing SQL SHUTDOWN command to the DB. Now I'm trying to introduce that in some unobtrusive way - I hit the DB via Hibernate - maybe subclassing the DataSource would work. I'll see what I can come up with and report back. 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 -- Cheers, Jakub - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Best regards, Paul Szulc http://paulszulc.wordpress.com
Re: Jetty, HSQLDB and automatic scanning
I found that (here: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1114) exactly ten minutes ago and was just about to post back here :) . What's important - it works, so my connection string looks like this: jdbc:hsqldb:file:temp_db;shutdown=true Thanks for all the ideas! On Fri, May 28, 2010 at 11:07 AM, Paul Szulc paul.sz...@gmail.com wrote: maybe you lack of shutdown=true ? shutdown=true shuts when connections are closed On Fri, May 28, 2010 at 10:53 AM, Jakub Skoczen skoc...@gmail.com wrote: (sorry if that gotten reposted, I mistakenly used a different email address that may have not been registered with the ML) On Thu, May 27, 2010 at 7:00 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: you can add a servlet context listener that looks for the lock file and nukes it. I had a similar idea for a while but hoped for a cleaner approach. Anyways after reading through the docs it looks like HSQLDB is using the standard Java lock file that gets released when the JVM exits, hence the issue. Nevertheless, you can force it to remove the lock by issuing SQL SHUTDOWN command to the DB. Now I'm trying to introduce that in some unobtrusive way - I hit the DB via Hibernate - maybe subclassing the DataSource would work. I'll see what I can come up with and report back. 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 -- Cheers, Jakub - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Best regards, Paul Szulc http://paulszulc.wordpress.com -- Cheers, Jakub - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Jetty, HSQLDB and automatic scanning
cool On Fri, May 28, 2010 at 11:49 AM, Jakub Skoczen skoc...@gmail.com wrote: I found that (here: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1114) exactly ten minutes ago and was just about to post back here :) . What's important - it works, so my connection string looks like this: jdbc:hsqldb:file:temp_db;shutdown=true Thanks for all the ideas! On Fri, May 28, 2010 at 11:07 AM, Paul Szulc paul.sz...@gmail.com wrote: maybe you lack of shutdown=true ? shutdown=true shuts when connections are closed On Fri, May 28, 2010 at 10:53 AM, Jakub Skoczen skoc...@gmail.com wrote: (sorry if that gotten reposted, I mistakenly used a different email address that may have not been registered with the ML) On Thu, May 27, 2010 at 7:00 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: you can add a servlet context listener that looks for the lock file and nukes it. I had a similar idea for a while but hoped for a cleaner approach. Anyways after reading through the docs it looks like HSQLDB is using the standard Java lock file that gets released when the JVM exits, hence the issue. Nevertheless, you can force it to remove the lock by issuing SQL SHUTDOWN command to the DB. Now I'm trying to introduce that in some unobtrusive way - I hit the DB via Hibernate - maybe subclassing the DataSource would work. I'll see what I can come up with and report back. 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 -- Cheers, Jakub - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Best regards, Paul Szulc http://paulszulc.wordpress.com -- Cheers, Jakub - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Best regards, Paul Szulc http://paulszulc.wordpress.com
Jetty, HSQLDB and automatic scanning
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
Re: Jetty, HSQLDB and automatic scanning
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
Re: Jetty, HSQLDB and automatic scanning
maybe you should properly shutdown hsqldb in Application#onDestroy() ... Am 27.05.2010 um 19:00 schrieb Igor Vaynberg: 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
