*** BREAKING CHANGES COMING UP SOON ***

[Marius]

Folks,

I spent a few days decoupling Lift from JEE web container
dependencies: javax.servlet._ The code is currently in wip-marius-http-
abstractions.

I still need to nail down a few things but the idea is:

1. Lift will work with its own traits that abstracts HTTP request,
response, HTTP sessions etc.
2. By default there will be the servlet implementation and it'll work
as currently.
3. Certain function names will slightly change.
4. If your application explicitly wants to use HttpServletRequest
obtained from S some explicit casts would be needed. Generally Lift
application should probably not explicitly use javax.servlet._
references.

I will post the details of the changes when I'll merge it to master
(hopefully this week).

Br's,
Marius

[Derek Chen-Becker]

I don't necessarily have a problem with this, but what's the gain? Are there other HTTP frameworks that don't use the javax.servlet API? Just curious.

Derek

[David Pollak]

On Tue, Aug 4, 2009 at 1:37 PM, Derek Chen-Becker <dchen...@gmail.com> wrote:

I don't necessarily have a problem with this, but what's the gain? Are there other HTTP frameworks that don't use the javax.servlet API? Just curious.

Yes, Jersey directly, portlets, etc.

Derek

On Tue, Aug 4, 2009 at 1:51 PM, Marius <marius...@gmail.com> wrote:

Folks,

I spent a few days decoupling Lift from JEE web container
dependencies: javax.servlet._ The code is currently in wip-marius-http-
abstractions.

I still need to nail down a few things but the idea is:

1. Lift will work with its own traits that abstracts HTTP request,
response, HTTP sessions etc.
2. By default there will be the servlet implementation and it'll work
as currently.
3. Certain function names will slightly change.
4. If your application explicitly wants to use HttpServletRequest
obtained from S some explicit casts would be needed. Generally Lift
application should probably not explicitly use javax.servlet._
references.

I will post the details of the changes when I'll merge it to master
(hopefully this week).

Br's,
Marius

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[Derek Chen-Becker]

Cool. I'll have to look at portlets and see what they do.

Derek

[marius d.]

Things like AsyncWeb, some HTTP stacks on top of Netty ...

Br's,
Marius

On Aug 4, 11:37 pm, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
> I don't necessarily have a problem with this, but what's the gain? Are there
> other HTTP frameworks that don't use the javax.servlet API? Just curious.
>
> Derek
>

[Timothy Perrett]

Portlets have some mixed press, so im not sure how much of a win that
will be. The AsyncWeb / Netty stuff does look pretty freaking cool
tho.

Cheers, Tim

On Aug 4, 10:40 pm, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
> Cool. I'll have to look at portlets and see what they do.
>
> Derek
>
> On Tue, Aug 4, 2009 at 2:38 PM, David Pollak

> <feeder.of.the.be...@gmail.com>wrote:

>
>
>
>
>
> > On Tue, Aug 4, 2009 at 1:37 PM, Derek Chen-Becker <dchenbec...@gmail.com>wrote:
>
> >> I don't necessarily have a problem with this, but what's the gain? Are
> >> there other HTTP frameworks that don't use the javax.servlet API? Just
> >> curious.
>
> > Yes, Jersey directly, portlets, etc.
>
> >> Derek
>

> >> On Tue, Aug 4, 2009 at 1:51 PM, Marius <marius.dan...@gmail.com> wrote:
>
> >>> Folks,
>
> >>> I spent a few days decoupling Lift from JEE web container
> >>> dependencies: javax.servlet._ The code is currently in wip-marius-http-
> >>> abstractions.
>
> >>> I still need to nail down a few things but the idea is:
>
> >>> 1. Lift will work with its own traits that abstracts HTTP request,
> >>> response, HTTP sessions etc.
> >>> 2. By default there will be the servlet implementation and it'll work
> >>> as currently.
> >>> 3. Certain function names will slightly change.
> >>> 4. If your application explicitly wants to use HttpServletRequest
> >>> obtained from S some explicit casts would be needed. Generally Lift
> >>> application should probably not explicitly use javax.servlet._
> >>> references.
>
> >>> I will post the details of the changes when I'll merge it to master
> >>> (hopefully this week).
>
> >>> Br's,
> >>> Marius
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net

> > Beginning Scalahttp://www.apress.com/book/view/1430219890

[Yousry Abdallah]

Could you setup a milestone before the merge?

[marius d.]

Sounds good to me

[Derek Chen-Becker]

Netty looks really cool. On a quick read it sounds maybe a little like MINA, although it definitely looks like it has a more high-level API to simplify things.

[Timothy Perrett]

We just rolled out a milestone release last night. 1.1-SNAPSHOT-M4

Cheers, Tim

[marius d.]

And looks to perform a bit better then MINA.

On Aug 5, 2:13 pm, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
> Netty looks really cool. On a quick read it sounds maybe a little like MINA,
> although it definitely looks like it has a more high-level API to simplify
> things.
>

[marius d.]

Dear all,

I'f committed today in the master the support for abstracting HTTP
stack in lift so that Lift itself does not depend on javax.servlet._
classes. This allows us to add support for Netty, AsyncWeb, etc. or
even your own implementation of a HTTP server etc.

This effort lead to several breaking changes:

1. S.servletRequest is now S.containerRequest, S.servletSession is now
S.containerSession. The reason is that the servlet term seems
inapropriate now as we not necessarily talking about servlets anymore.
2. LiftRules.enableServletSessions is now
LiftRules.enableContainerSessions

I won't enumerate here all methods from the new abstractions but the
traits are:

1. HTTPRequest
2. HTTPResponse
3. HTTPCookie
4. HTTPParam
5. HTTPProvider - This is the entry point in Lift. See how
ServletFilterProvider uses it.
6. HTTPSession
7. HTTPContext

To see how these trait map to JEE servlets world please see
refinements from net.liftweb.http.provider.servlet package

If your application does not explicitly relies on usage on
javax.servlet._ package you should have very little or no changes to
make.

Br's,
Marius

[Kevin Wright]

Impressive stuff :)

[David Pollak]

On Fri, Aug 7, 2009 at 12:35 PM, Kevin Wright <kev.lee...@googlemail.com> wrote:

Impressive stuff :)

+1

Way to go Marius.
 

--

Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890