[Lift] Less boilerplate in your specifications / tests

2010-02-28 Thread etorreborre
Hi all Lift-developers,

I have noticed a few commits recently where the declarations for
specifications could be reduced to something simpler.

For example:

import org.specs._
import org.specs.runner._

class BindingsSpecTest extends Runner(BindingsSpec) with JUnit with
Console
object BindingsSpec extends Specification

can be written as

import org.specs._

class BindingsSpec extends SpecificationWithJUnit

 - the BindingsSpec class will run with maven, provided that you add
the proper include directive in the pom.xml file, like this, for
example:

  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.4.3/version
configuration
  useSystemClassLoaderfalse/useSystemClassLoader
  argLine-Xmx512m/argLine
  forkModealways/forkMode
  includes
include**/*Unit.java/include
include**/*Spec.java/include
  /includes
  excludes
exclude**/*Test.java/exclude
  /excludes
/configuration
  /plugin

 - It will also run in the console, like this:

   scala -cp classpath run net.liftweb.http.BindingsSpec

I hope this helps, please ping me if you have any concern with this.

Eric.

PS: I forgot to mention that I am guilty of the situation above
because of how things were done in specs when I starting contributing
the first specifications to Lift,...

PPS: I've edited the User Guide to make clear what was the preferred
way of using JUnit with specs:

http://code.google.com/p/specs/wiki/RunningSpecs#Run_your_specification_with_JUnit4

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



[Lift] Re: Testing snippets that depend on a user logged in

2009-10-02 Thread etorreborre

Hi all,

I added a specs version as well.

Eric.

On Oct 2, 2:37 pm, Bill Venners b...@artima.com wrote:
 Hi Ryan, David, Eric,

 I added a ScalaTest version to your wiki page:

 http://wiki.github.com/dpp/liftweb/how-to-unit-test-lift-snippets-wit...

 Eric you may want to add a specs version.

 Bill





 On Thu, Oct 1, 2009 at 3:03 PM, rstradling ryanstradl...@gmail.com wrote:

  Awesome!!! Thanks guys for the help.  It now works.

  I put a how-to wiki document up on github.  For me this was one of
  those times where my google searches did not seem to turn up anything
  fruitful, so I thought this how-to would be helpful.  If it is not
  helpful, then no hard feelings if the page is deleted.  I just wanted
  to give back.

  Wiki page
 http://wiki.github.com/dpp/liftweb/how-to-unit-test-lift-snippets-wit...

  On Oct 1, 4:53 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
  Bill,
  Thanks for posting this.  I am, by experience (I started using it, I can 
  use
  it enough to write basic tests, I know no more) using Specs.  I would
  welcome and encourage some sample tests in Lift archetypes that use
  ScalaTest.  I want to make sure that folks who pick up Lift get to
  experience ScalaTest as well as Specs... that way, folks who have a better
  understanding of tests can make better choices.

  Thanks,

  David

  On Thu, Oct 1, 2009 at 1:27 PM, Bill Venners b...@artima.com wrote:

   Hi Ryan,

   It looks like you're currently using a JUnit TestCase. If you want an
   easier port to something that would work you could use a ScalaTest
   Suite like this:

   import org.scalatest.Suite

   class YourSuite extends Suite {

    val session = new LiftSession(, randomString(20), Empty)
    val stableTime = now

     override def withFixture(test: NoArgTest) {

      S.initIfUninitted(session) {
         val user = User.create
        user.firstName(XXX)
        user.lastName(YYY)
        user.save
        User.logUserIn(user)
         test()
       }
    }

    def testValue() {
     val xml =
         xml:group
           tr
               td
                   p:fullNameMy Name/p:fullName
               /td
               td
                   p:styleFighter Style/p:style
               /td
               td
                   p:weightWeight/p:weight
               /td
           /tr
         /xml:group
      val trainer = new Trainer()
      val output = trainer.showPeople(xml)
       // seems like you need an assertion here...
    }
   }

   A Suite considers methods that start with test as tests, like JUnit
   3, except they don't need to result in Unit so you don't need an extra
   () at the end. The withFixture method is an alternative to
   beforeEach/afterEach, which are like JUnit 3's setUp/tearDown methods.
   Each test gets passed as a function to withFixture, which is
   responsible for executing the test by invoking the function. In this
   case, it is executed in the context created by S. initIfUninitted.
   This is ScalaTest 1.0, which is available as a SNAPSHOT right now but
   should be released proper a week from Monday.

  http://www.artima.com/scalatest

   Bill

   On Thu, Oct 1, 2009 at 9:50 AM, David Pollak
   feeder.of.the.be...@gmail.com wrote:
Using Specs 1.6:

object HelloWorldTestSpecs extends Specification {
  val session = new LiftSession(, randomString(20), Empty)
  val stableTime = now
  override def executeExpectations(ex: Examples, t: =Any): Any = {
    S.initIfUninitted(session) {
      ... put your User init here.  The User.logUserIn will be within 
the
context of a session and thus session (and request) vars will be valid
    }
  }
  HelloWorld Snippet should {
    Put the time in the node in {
      ... do testing here
    }
  }
}

Hope this helps.
On Thu, Oct 1, 2009 at 8:55 AM, rstradling ryanstradl...@gmail.com
   wrote:

I have a class called
class Trainer {
  def showPeople(xhtml : Group) : NodeSeq = {
     val user : User = User.currentUser.open_!
     ...
  }
}

I then want to write a unit test to test that returns proper xml.

The test is written as so
 def testValue() = {
   val xml =
       xml:group
         tr
             td
                 p:fullNameMy Name/p:fullName
             /td
             td
                 p:styleFighter Style/p:style
             /td
             td
                 p:weightWeight/p:weight
             /td
         /tr
       /xml:group
   val trainer = new Trainer()
   val output = trainer.showPeople(xml)
   ()
 }

The User object inherits from MegaProtoUser.

The problem is I am not sure how to create a mock user and sign them
in.
I have tried in my unit test
override def setUp : Unit = {
  val user = User.create
  user.firstName(XXX)
  user.lastName(YYY)
  user.save
  User.logUserIn(user)
  

[Lift] Re: Testing snippets that depend on a user logged in

2009-10-01 Thread etorreborre

Hi,

I am working at the moment on a small lift demo app and I've added
some enhancements to specs in order to ease the testing inside a
session.
To use those functionalities, you need specs-1.6.1-SNAPSHOT (http://
www.scala-tools.org/repo-snapshots/org/scala-tools/testing/specs/1.6.1-SNAPSHOT).

Here are the specification and traits that I use to test the JPA
requests to save a User in the database:

// First I create Mocks for the lift session
import javax.servlet.http._
import net.liftweb.http.{ S, Req, LiftSession }
import org.specs.mock.Mockito

trait MockRequest extends Mockito { this: Specification =
  var request = mock[Req]
  var httpRequest = mock[HttpServletRequest]
  var session = mock[LiftSession]

  def createMocks: Unit = {
 request = mock[Req]
 httpRequest = mock[HttpServletRequest]
 session = mock[LiftSession]
 request.request returns httpRequest
  }

   // this method can be used to executed any action inside a mocked
session
  def inSession(f: =Any) {  S.init(request, session) { f }  }

   def unsetParameter(name: String) { request.param(name) returns
None }
   def setParameter(name: String, value: String)  { request.param
(name) returns Some(value) }
}

// Context creation for the specification
//
// This Specification context specifies the User table must be
cleaned up before each example.
//  It also makes sure that the example expectations are executed in a
mocked session
// see 
http://code.google.com/p/specs/wiki/DeclareSpecifications#Specification_context_(_from_1.6.1_)
for more information

object DatabaseContext extends Specification with Contexts with
MockRequest {
  val setup = new SpecContext {
beforeExample(inSession(Users.createQuery(delete
User).executeUpdate)) // delete the User table before each example
aroundExpectations(inSession(_))  // execute each example inside a
mocked session
  }
}

// and finally the specification itself

import org.specs._
import org.specs.specification._

class UserSpec extends SpecificationWithJUnit with MockRequest with
Contexts {

  DatabaseContext.setup(this) // set the specification context on this
specification

  A Users repository can {
create a user in {
   val eric = User(etorreborre, password, Eric)
   Users.mergeAndFlush(eric) // the Users object is a LocalEMF
with RequestVarEM so it needs a session
   Users.find(classOf[User], etorreborre) must_== Some(eric)
}
  }
   A Users repository should {
 throw an exception if the user name has a length  5 in {
Users.merge(User(e, password, Eric)) must throwAn
[Exception]
 }
  }
}

I hope this helps too, please ask if you have any questions.

Eric.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---



[Lift] Lift and Hibernate validators

2009-09-28 Thread etorreborre

Hi,

I'm trying to get a Lift/JPA demo rolling but I can't get Scala work
with Hibernate validators (as it has been noticed before:
https://lampsvn.epfl.ch/trac/scala/ticket/1846,
https://lampsvn.epfl.ch/trac/scala/ticket/2245,
https://lampsvn.epfl.ch/trac/scala/ticket/2252).

My question is: what's your preferred workaround for this issue when
using Lift/JPA?

Thanks,

Eric.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---



[Lift] Wicket vs Tapestry vs Grails vs Lift?

2009-09-16 Thread etorreborre

Hi,

Anyone is interested in coding the same app with Lift and have a look
at the numbers?

http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails

Eric.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---



[Lift] Re: unit test framework

2009-07-02 Thread etorreborre

Hi Bill and ph,

Using specs matchers inside a JUnit test class is also possible using
the org.specs.SpecsMatchers trait.

However, I realize that both ScalaTest and specs suffer from the same
issue in that scenario.
When expectations are failing an exception is thrown but it is
interpreted by JUnit as an error instead of a failure.

We should instead throw an AssertionFailedError from the junit
library.

That shouldn't be a big deal to fix.

Eric.

On Jul 3, 10:34 am, Bill Venners b...@artima.com wrote:
 Hi ph,

 If you end up needing to use JUnit, you can import Assertions or
 ShouldMatchers or MustMatchers from ScalaTest to get a nicer
 scala-like assertion syntax inside JUnit tests. JUnit won't care it
 was written in Scala or used ScalaTest assertions and will run it and
 generate JUnit-compatible output, since it actually is JUnit. Here's
 what that might look like:

 import org.junit.Test
 import org.scalatest.matchers.MustMatchers._

 class MyJUnitTest {
   @Test
   def mapKeys() {
     Map(one - 1, two - 2) must contain key (two)
   }
   @Test
   def stringLength() {
     hello, world must have length (12)
   }
   @Test
   def stringCharAtMethodRejectsBadInput() {
     intercept[StringIndexOutOfBoundsException] {
       hi.charAt(-1)
     }
   }

 }

 http://www.artima.com/scalatest

 Bill





 On Wed, Jul 1, 2009 at 3:07 PM, phpkirsa...@gmail.com wrote:

  This question might be obvious to most of the people here, but since I
  new to Scala and Java I'm not clear

  Maven generates 2 different unit test files:
  MySpec  specs
  AppTest  junit

  running mvn test invokes AppTest (and other test cases with
  annotation @Test)
  running from Eclipse project as JUnit invokes MySpec

  I'm trying to figure out what unit test framework to use in my
  project. I'd prefer to have JUnit compatible output as continuous
  build system will, probably, understand it.

  Are both test frameworks generate JUnit-compatible output?
  How to make maven invoke specs test when running mvn test?
  Why is it 2 different test frameworks used? Are they complimentary? If
  yes when use which?
  I will probably use Hudson for continuous builds and also invoke unit
  tests from script and or command line and will need parse result and
  generate reports. What framework is better for these purposes? Or
  maybe use both in defferent cases?

 --
 Bill Venners
 Artima, Inc.http://www.artima.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---



[Lift] Re: unit test framework

2009-07-01 Thread etorreborre

Hi,

My understanding is that historically the first tests for lift were
proposed as JUnit tests.
Then I implemented a few tests using specs (which I created), mostly
for the lift-util module.

Now, to answer your question, specs is compatible with JUnit, so you
can write specs and make them runnable with JUnit by writing:

class MySpec extends SpecificationWithJUnit {
  
}
[note1: that this is with specs-1.5.1-SNAPSHOT, with 1.5.0 you would
write extends Specification with JUnit. This was changed to remove
junit dependencies on the Specification class].
[note2: the other, more verbose way, of doing the same thing is to
declare:

class MySpecTest extend org.specs.runner.JUnit(MySpec)
object MySpec extends Specification
]

Then you can also run this specification from the command line with:

scala -cp ... run MySpec

So I would say that eventually this comes down to a matter of taste
when writing tests, whether you prefer the junit or specs syntax.

Eric.

On Jul 2, 8:07 am, ph pkirsa...@gmail.com wrote:
 This question might be obvious to most of the people here, but since I
 new to Scala and Java I'm not clear

 Maven generates 2 different unit test files:
 MySpec  specs
 AppTest  junit

 running mvn test invokes AppTest (and other test cases with
 annotation @Test)
 running from Eclipse project as JUnit invokes MySpec

 I'm trying to figure out what unit test framework to use in my
 project. I'd prefer to have JUnit compatible output as continuous
 build system will, probably, understand it.

 Are both test frameworks generate JUnit-compatible output?
 How to make maven invoke specs test when running mvn test?
 Why is it 2 different test frameworks used? Are they complimentary? If
 yes when use which?
 I will probably use Hudson for continuous builds and also invoke unit
 tests from script and or command line and will need parse result and
 generate reports. What framework is better for these purposes? Or
 maybe use both in defferent cases?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---



[Lift] Re: Hudson for Scala-tools.org is back online

2009-04-16 Thread etorreborre

Thanks David!

And now I can happily see that I've just passed the 1000 tests bar:
http://hudson.scala-tools.org/job/specs,...

Eric.

On Apr 17, 7:16 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
 Folks,

 I've put hudson back online... it's available athttp://hudson.scala-tools.org

 If you've got a project that should be in Hudson but is not or if Hudson is
 failing to build your project, please send mail to admin [at] scala-tools
 [dot] org and we'll clean it up.

 Thanks,

 David

 PS -- Nexus is next

 --
 Lift, the simply functional web frameworkhttp://liftweb.net
 Beginning Scalahttp://www.apress.com/book/view/1430219890
 Follow me:http://twitter.com/dpp
 Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---



[Lift] Wiki example with specs and Mockito

2009-04-02 Thread etorreborre

Hi,

The Wiki example specification, which was previously specified using
JMock broke when we migrated to Scala 2.7.2 (compiler issue, couldn't
solve it).

However, the latest version of specs (1.4.4-SNAPSHOT) provides an
integration with Mockito which is even nicer when just doing stubbing.
So the Wiki Specification is now back on track and you can pull it
from git.

I want to note also one thing. The way the original example was
written wasn't very stub-friendly, so I had to change:

object WikiEntry extends WikiEntry with LongKeyedMetaMapper[WikiEntry]

to

object WikiEntry extends MetaWikiEntry // introduced the MetaWikiEntry
trait
trait MetaWikiEntry extends WikiEntry with LongKeyedMetaMapper
[WikiEntry]

and

class Wiki {
import WikiEntry._

to

// using the MetaWikiEntry trait to stub the database accesses
class Wiki extends MetaWikiEntry {

My hope is that Powermock (http://code.google.com/p/powermock) is
going to catchup with the latest version of Mockito and that we'll be
able to mock/stub any static method. In the meantime, I would advise
to avoid static imports, like import WikiEntry._ to facilitate
specifications/testing.

Cheers,

Eric.




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---



[Lift] Re: Build Comet applications using Scala, Lift, and jQuery

2009-03-26 Thread etorreborre

Anyone can comment the ServerSide article:
http://www.theserverside.com/news/thread.tss?thread_id=54079?

There are questions on accessibility and a template engine.

Eric.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---



[Lift] Re: You guys rock!

2009-03-11 Thread etorreborre

Hi Alex,

Knowing that you can write specs which can be run as JUnit tests,
can't the continuous testing plugin in Eclipse work with that?

Or would you like something simple like autotest in Ruby which polls
the modified files regularly and executes the tests in the console if
any file is modified? I've just seen someone creating a FilePoller in
Scala. I could certainly make a good use of it then.

Eric.

PS:

BTW, the next version of specs allows you to mix-in a JUnit trait (or
ScalaTest) to a Specification like this:

class mySpec extends Specification with JUnit { ... }

The only difference with before is that your specification has to be a
class. And in that case, if you want to execute it in the console you
need to do:

// if mySpec is a class, the run class can be used to execute it
java -cp ... run org.mypackage.mySpec

One more thing to note, if you're a Maven user (I don't remember how
Buildr does it), you have to be careful about the Specification class
naming because by default only **/*Test files are included. I recently
made sure that all my Specifications in the project were named xxxSpec
and Unit, and I configured Maven to execute only those.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---



[Lift] Re: How can I use unit tests with S.?(key) ?

2009-03-11 Thread etorreborre

Hi,

I don't know how this could help because I've been away from lift code
for a long time. But I remember that I tried to use mocks with JMock
and specs in order to specify the example site (\liftweb\sites
\example\src\test\scala\net\liftweb\example\snippet).

The idea was to simulate a session:

inSession {
 // do your test here
}

This works with the following code (see the WikiSpec.scala file):


class MockRequest extends Specification with JMocker with ClassMocker
{
  var request: Req = mock[Req]
  var httpRequest: HttpServletRequest = mock[HttpServletRequest]
  var session: LiftSession = mock[LiftSession]
  def createMocks = {
request = mock[Req]
httpRequest = mock[HttpServletRequest]
session = mock[LiftSession]
expect {
  0.atLeastOf(httpRequest).getCookies
  0.atLeastOf(request).request.willReturn(httpRequest)
}
  }
  def inSession(f: = Any) {
S.init(request, session) {
  f
}
  }
  def unsetParameter(name: String) {
expect {
  0.atLeastOf(request).param(equal(name)).willReturn(None)
}
  }
  def setParameter(name: String, value: String) {
expect {
  0.atLeastOf(request).param(equal(name)).willReturn(Some(value))
}
  }
}



Unfortunately, I remember that we had compilation issues when
upgrading to scala-2.7.2 and as a result, most of the code is
commented out.

I've recently started to integrate Mockito and Powermock to specs and
that may prove a decent way to support unit testing using S methods.

Eric.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---



[Lift] [ANN] New specs release: 1.4.3

2009-02-11 Thread etorreborre

Hi,

I would like to announce a new specs release, 1.4.3.

This release fixes the following issues:

-issue 50: subexamples reporting
-issue 51, 53: behave like is not working
-issue 55: beIn, notBeIn restrictions
-timer displaying a total time of 0 for composed specifications
executed in the Console

-ScalaCheck's forAll function was hidden by a function with the same
name in the ScalaCheckFunctions trait. Fixing this issue now allows to
fix the deprecation warnings from ScalaCheck 1.5 when using the
property function. This will allow to clean up the lift code re.
those warnings.

And introduces few new features:

-a -xOnly or --failedOnly option to only display failures and
errors in the console
-a beOneOf matcher
-a containMatchOnlyOnce matcher

I also get the opportunity of this release to present the specs
library once more for newcomers on this list ;-)

specs is a Behaviour-Driven-Design framework which provides:

- a simple and typed language to create software specifications:

object helloWorld extends Specification {
  'hello world' has 11 characters in {
 hello world.size must beEqualTo(11)
  }
  'hello world' matches 'h.* w.*' in {
 hello world must beMatching(h.* w.*)
  }
}


- lots of matchers to specify code properties:

 myString must beMatching(Str.*)

 // or to specify xml pieces using XPath-like operators:
 cd/d/c must \\(c).\(d)

- an integration with JUnit to so that you can run and report your
tests using your existing infrastructure

- an easy way to specify combinatorial properties through an
integration with ScalaCheck:

// generates 500 different mail addresses
mailAddresses must pass { address =
  address must beMatching(companyPattern)
}

- an integration with jMock2

- and much, much more,... See the User Guide: 
http://code.google.com/p/specs/wiki/UserGuide.

Happy specs!

Eric.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---



Re: Fwd: [Lift] Cleaning up warnings

2009-02-02 Thread etorreborre

Hi David and Rickard,

If you replace property(...) by Prop.forAll(...), the warnings should
disappear.

On the other hand I don't know why forAll(...) only doesn't work.

Cheers,

Eric.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---