Yeah the dependencies section of Jetty is pretty nifty. I had this same problem using Tibco messaging tibrvj.jar in my war causing jetty fail when reloading an application. In the case of Tibco I had to still keep it as a regular dependency with <scope>provided</scope> so that I could compile but I was able to entirely remove derby as project dependency. Of course when I start writing some unit tests I'll probably have to add it back with <scope>test</scope> but I'm more interested in getting deeper into Lift framework, which as been a fun journey so far. =)
Not sure if I should put something in the issue manager or not. I would be more than happy to put in an issue and submit a patch. Cheers! On Dec 13, 7:03 pm, Tim Nelson <tnell...@gmail.com> wrote: > I had the same problem while using H2. I solved it by disposing the db > connections when the servlet is destroyed. I wrote a gist about it > here:http://gist.github.com/166687 > > I don't think I've ever seen your solution, which might be a better > way to handle it. > > Tim > > On Sun, Dec 13, 2009 at 3:41 PM, joseph hirn <joseph.h...@gmail.com> wrote: > > I just started looking into lift today but I ran into an issue where I > > could not make hot changes to class files without having to restart > > jetty because Derby would complain it was already bound. I was > > searching around on here and found this issue: > >http://groups.google.com/group/liftweb/browse_thread/thread/9dcf84464... > > > I've had simlilar issues with embedded libraries before and I was able > > to resolve this issue by making derby a dependency in jetty rather > > than of the app like so: > > > <plugin> > > <groupId>org.mortbay.jetty</groupId> > > <artifactId>maven-jetty-plugin</artifactId> > > <configuration> > > <contextPath>/</contextPath> > > <scanIntervalSeconds>5</scanIntervalSeconds> > > </configuration> > > <dependencies> > > <dependency> > > <groupId>org.apache.derby</groupId> > > <artifactId>derby</artifactId> > > <version>10.4.2.0</version> > > </dependency> > > </dependencies> > > </plugin> > > > Not only does this make Jetty manage Derby so redeploying will not > > create a new Derby instance but it also keeps the app database > > independent. You can then either remove Derby as a regular dependency > > or put it as <scope>provided</scope> so that Maven will not package it > > in your warfile. > > > Is anyone else having this issue? Should I open a ticket in the issue > > tracker for the archetype? Maybe everyone knows to do this but it was > > annoying for a first timer like me who just started with the > > archetype, especially after the annoyance that archetype:generate menu > > generates an old archetype and won't upgrade to v1.0. > > > Thanks! > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to lift...@googlegroups.com. > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
