[Lift] Re: *** BREAKING CHANGES COMMITTED ***
On Fri, Aug 7, 2009 at 12:35 PM, Kevin Wright wrote: > Impressive stuff :) +1 Way to go Marius. > > > On Fri, Aug 7, 2009 at 6:54 PM, marius d. wrote: > >> >> 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 >> >> On Aug 5, 3:05 pm, "marius d." wrote: >> > And looks to perform a bit better then MINA. >> > >> > On Aug 5, 2:13 pm, Derek Chen-Becker 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. >> > >> > > On Wed, Aug 5, 2009 at 5:08 AM, marius d. >> wrote: >> > >> > > > Sounds good to me >> > >> > > > On Aug 5, 1:51 pm, Yousry Abdallah wrote: >> > > > > Could you setup a milestone before the merge? >> > >> > > > > On 4 Aug., 21:51, Marius 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 --~--~-~--~~~---~--~~ 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: *** BREAKING CHANGES COMMITTED ***
Impressive stuff :) On Fri, Aug 7, 2009 at 6:54 PM, marius d. wrote: > > 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 > > On Aug 5, 3:05 pm, "marius d." wrote: > > And looks to perform a bit better then MINA. > > > > On Aug 5, 2:13 pm, Derek Chen-Becker 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. > > > > > On Wed, Aug 5, 2009 at 5:08 AM, marius d. > wrote: > > > > > > Sounds good to me > > > > > > On Aug 5, 1:51 pm, Yousry Abdallah wrote: > > > > > Could you setup a milestone before the merge? > > > > > > > On 4 Aug., 21:51, Marius 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 > > > --~--~-~--~~~---~--~~ 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: *** BREAKING CHANGES COMMITTED ***
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 On Aug 5, 3:05 pm, "marius d." wrote: > And looks to perform a bit better then MINA. > > On Aug 5, 2:13 pm, Derek Chen-Becker 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. > > > On Wed, Aug 5, 2009 at 5:08 AM, marius d. wrote: > > > > Sounds good to me > > > > On Aug 5, 1:51 pm, Yousry Abdallah wrote: > > > > Could you setup a milestone before the merge? > > > > > On 4 Aug., 21:51, Marius 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
