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 withprovided 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 withtest 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.
>
> Cheers!
>
> On Dec 13, 7:03 pm, Tim Nelson 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 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:
>>
>>>
>>> org.mortbay.jetty
>>> maven-jetty-plugin
>>>
>>>/
>>>5
>>>
>>>
>>>
>>> org.apache.derby
>>> derby
>>> 10.4.2.0
>>>
>>>
>>>
>>
>>> 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 asprovided 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.
>
>
--
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.
