Jetty/Derby, unable to redeploy hot changes (FIXED)

[joseph hirn]

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/9dcf84464dc07cce/c0cadcc4e6a3b472?lnk=gst&q=Another+instance+of+Derby#c0cadcc4e6a3b472

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!

[Tim Nelson]

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

> --
>
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
>
>
>

[Alex Boisvert]

Yes, putting any JDBC driver into the container's classpath (i.e., Jetty) is the better way. 

Otherwise, if you put the driver into the .war, you'll most likely end up with class / permgen leakage if you redeploy your webapp.   (Because java.sql.Driver holds a reference to all loaded drivers)

alex

[joseph hirn]

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...

[Indrajit Raychaudhuri]

On 14/12/09 8:54 AM, joseph hirn wrote:
> 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. =)

'provided' scope dependency is available in test classpath as well. It's
not transitive though.

>
> 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.

Sure, file a ticket describing the issue and your recommended solution.