Ok, thanks :) I will continue like that! (I actually stopped using hibernate, but the same situation happens when using jdbi, we need an environment).
Le jeudi 10 novembre 2016 06:44:29 UTC+1, Evan Meagher a écrit : > > I think that your best bet is to continue with your solution of extracting > the `SessionFactoryManager` from the list of managed objects. The > `SessionFactoryManager`'s state changes boil down to starting and stopping > the underlying `javax.sql.DataSource` object, which isn't exposed directly. > The only way that I see to tickle it is via the managed object. > > On Tue, Nov 8, 2016 at 4:55 AM, <[email protected] <javascript:>> wrote: > >> Hi, >> >> I'm trying to implement an EnvironmentCommand (it needs to be environment >> because I want to exploits my application hibernate bundle and it needs to >> be initialised and stuffs). >> >> My problem is that it seems that since the hibernate/datasource/etc >> resources are normally managed by Jetty's lifecycle management, they are >> not managed when used in a command. >> >> The problem is not always visible (because everything is closed/killed on >> JVM stop), but when running a command with maven exec plugin, for example, >> it detects that some things are not clean as they should: >> [WARNING] thread Thread[Tomcat JDBC Pool >> Cleaner[1981821368:1478608496356],5,org.ow2.petals.cockpit.server.CockpitApplication] >> >> was interrupted but is still alive after waiting at least 15000msecs >> [WARNING] thread Thread[Tomcat JDBC Pool >> Cleaner[1981821368:1478608496356],5,org.ow2.petals.cockpit.server.CockpitApplication] >> >> will linger despite being asked to die via interruption >> [WARNING] thread Thread[MVStore background writer >> nio:/home/vnoel/Linagora/Petals/dev/git/petals-cockpit-new/cockpit.mv.db,5,org.ow2.petals.cockpit.server.CockpitApplication] >> >> will linger despite being asked to die via interruption >> [WARNING] NOTE: 2 thread(s) did not finish despite being asked to via >> interruption. This is not a problem with exec:java, it is a problem with >> the running code. Although not serious, it should be remedied. >> >> I found a workaround by starting the lifecycles at the beginning of my >> command's run method and stopping them at the end of it with: >> >> for (LifeCycle lf : >> environment.lifecycle().getManagedObjects()) { >> // start/stop >> } >> >> But it seems a bit complex, is there a simpler way to do that? >> Maybe dropwizard could implement such functionality, no? >> >> Thanks >> >> Victor >> >> -- >> You received this message because you are subscribed to the Google Groups >> "dropwizard-user" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Evan Meagher > -- You received this message because you are subscribed to the Google Groups "dropwizard-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
