**Breaking Changes** **README** **Important**

[David Pollak]

Folks,

As the title of this email indicates, there are breaking changes in Lift that just got pushed to master.

We've migrated from Scala Actors to Lift Actors and included a series of traits that allow Lift to use its own Actors or Akka Actors (or anything else that implements that interface.)

The two big changes that you'll have to work with are:

• Box/Full/Empty/Failure was moved from the lift-util/net.liftweb.util package to the lift-common/net.liftweb.common package.  The reason for this change is that we're going to make the lift-common package a more generic, non-web related package.  It currently contains Box and Actor, but in the future may contain other interfaces that will have concrete implementations outside of Lift.  We moved Box there because Box is richer than Scala's Option class and being able to carry Exceptions around in a Box while still being able to map/flatMap/foreach over a Box (these are unavailable for Scala's Either).  Some we're going to actively promote using Box as a replacement for Option in all Scala apps.  What this means for you is you have to import net.liftweb.common._ in any file that you also import net.liftweb.util.? 
• Lift no longer support Scala Actors for Comet Actors.  The GenericActor API offers pretty much the same client interface to Lift's Actors, so ! and !? work the same way.  However, there's no link, self, start or exit methods.  

Please do an "mvn -U clean install" on your code and run it against the new code.  If you have any Comet-related weirdness, please report it immediately.  We're planning M7 in 2 weeks, so we've got lots of time to iron any kinks out of this code.

Thanks,

David

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

[Jonathan Ferguson]

Do we need to update our pom's or should it be code changes only ?

Cheers 

Jono

2009/10/22 David Pollak <feeder.of...@gmail.com>

[David Pollak]

On Wed, Oct 21, 2009 at 10:27 PM, Jonathan Ferguson <jo...@spiralarm.com> wrote:

Do we need to update our pom's or should it be code changes only ?

You likely only need to make the code change... at least that's been the case for all the projects I've converted.

[Indrajit Raychaudhuri]

Code change should suffice.

pom.xml updates won't be necessary since lift-util has lift-common as
dependency and your application (which must be having lift-util as
dependency) would resolve the lift-common dependency transitively.

Cheers, Indrajit

On 22/10/09 10:57 AM, Jonathan Ferguson wrote:
> Do we need to update our pom's or should it be code changes only ?
>
> Cheers
>
> Jono
>
> 2009/10/22 David Pollak <feeder.of...@gmail.com

> <mailto:feeder.of...@gmail.com>>

>
> Folks,
>
> As the title of this email indicates, there are breaking changes in
> Lift that just got pushed to master.
>
> We've migrated from Scala Actors to Lift Actors and included a
> series of traits that allow Lift to use its own Actors or Akka
> Actors (or anything else that implements that interface.)
>
> The two big changes that you'll have to work with are:
>

> * Box/Full/Empty/Failure was moved from the

> lift-util/net.liftweb.util package to the
> lift-common/net.liftweb.common package. The reason for this
> change is that we're going to make the lift-common package a
> more generic, non-web related package. It currently contains
> Box and Actor, but in the future may contain other interfaces
> that will have concrete implementations outside of Lift. We
> moved Box there because Box is richer than Scala's Option
> class and being able to carry Exceptions around in a Box while
> still being able to map/flatMap/foreach over a Box (these are
> unavailable for Scala's Either). Some we're going to actively
> promote using Box as a replacement for Option in all Scala
> apps. What this means for you is you have to import
> net.liftweb.common._ in any file that you also import
> net.liftweb.util.?

> * Lift no longer support Scala Actors for Comet Actors. The

[Jonathan Ferguson]

You're right, my bad - an old pom was looking at the wrong repo, all happy now.

[soumik]

Hi,
I've a few question regarding the changes made.
- Firstly, with the changes made, how do I have a method which can now
accept both scala Actor as well as a CometActor??
Prior to the changes, I had a function "def registerActor(act:
Actor) which could handle both scala Actor as well as CometActor,; now
if I change this to "def registerActor(act: GenericActor)" it throws
compilation error asking to a type to be specified for the
GenericActor. What change would you suggest to have my code compile?
- Secondly, I also get compilation error for calling
scheduleAtFixedRate method on ActorPing. Says no such method. Has this
method been deprecated and if so, what is the method I should be
calling instead?

Thanks,
Soumik

On Oct 22, 10:35 am, Indrajit Raychaudhuri <indraj...@gmail.com>
wrote:

> Code change should suffice.
>
> pom.xml updates won't be necessary since lift-util has lift-common as
> dependency and your application (which must be having lift-util as
> dependency) would resolve the lift-common dependency transitively.
>
> Cheers, Indrajit
>
> On 22/10/09 10:57 AM, Jonathan Ferguson wrote:
>
> > Do we need to update our pom's or should it be code changes only ?
>
> > Cheers
>
> > Jono
>

> > 2009/10/22 David Pollak <feeder.of.the.be...@gmail.com
> > <mailto:feeder.of.the.be...@gmail.com>>

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

[george]

> - Secondly, I also get compilation error for calling
> scheduleAtFixedRate method on ActorPing. Says no such method. Has this
> method been deprecated and if so, what is the method I should be
> calling instead?

I have this problem also.

[Viktor Klang]

DPP (and I) recommend just doing schedule and then re-schedule after message recieved.

schedule(actor,MyMsg(),3 seconds)

in the actor

{
   case MyMsg() => {
                                doMyStuff
                                schedule(this,MyMsg(),3 seconds)
    }
}

Makes sense?

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: viktorklang
Code: github.com/viktorklang

[Timothy Perrett]

Guys,

>   Prior to the changes, I had a function "def registerActor(act:
> Actor) which could handle both scala Actor as well as CometActor,; now
> if I change this to "def registerActor(act: GenericActor)" it throws
> compilation error asking to a type to be specified for the
> GenericActor. What change would you suggest to have my code compile?

Checkout the declaration:

trait GenericActor[R] extends TypedActor[Any, R]

You need to pass it a type argument to populate R in order for your
code to compile.

> - Secondly, I also get compilation error for calling
> scheduleAtFixedRate method on ActorPing. Says no such method. Has this
> method been deprecated and if so, what is the method I should be
> calling instead?

If I remember rightly there was a discussion about this on list not so
long ago - looking at the code, scheduleAtFixedRate has been removed.
The preferred idiom is to generally have a method that reschedules the
actor on every "ping".

Cheers, Tim

[george]

ok so..

object LocalSmtp extends Actor

should become

object LocalSmtp extends GenericActor[LocalSmtp]

?

[Dano]

It would be good to have an example like George's verified as it is
not clear how to convert our Actor code.



Dan

[Dano]

I did a quick check in the lift sources and could not find example or
test code for the new LiftActors. Perhaps additions to these areas
would help those that are trying to convert their Actor code.

Thanks in advance for any help for those still struggling to make the
conversion.


Dan

[Dano]

Code for our app now compiles. Needed to replace Actor with
LiftActor. Also, needed to define the messageHandler partial
function.

So, George, I think the answer to your question is:

object LocalSmtp extends Actor

becomes

object LocalSmtp extends LiftActor


Dan

[george]

Thanks Dan, I will try that.

[ssid]

Hi all,
I'm using XMPP in my little LiftApp and tried to migrate my code to
the new Lift Actors.
Somehow it seems that net.liftweb.xmpp still uses Scala Actors.
Is this intentional or about to change?
If not is it possible that Scala Actors communicate with Lift Actors?
At the moment I don't get my project to compile due to some type
mismatch errors but that might also be my lack of understanding
of the different Actor implementations.

Thanks,
ssid

On 22 Okt., 05:37, David Pollak <feeder.of.the.be...@gmail.com> wrote:
> Folks,
> As the title of this email indicates, there are breaking changes in Lift
> that just got pushed to master.
>
> We've migrated from Scala Actors to Lift Actors and included a series of
> traits that allow Lift to use its own Actors or Akka Actors (or anything
> else that implements that interface.)
>
> The two big changes that you'll have to work with are:
>

>    - Box/Full/Empty/Failure was moved from the lift-util/net.liftweb.util

>    package to the lift-common/net.liftweb.common package.  The reason for this
>    change is that we're going to make the lift-common package a more generic,
>    non-web related package.  It currently contains Box and Actor, but in the
>    future may contain other interfaces that will have concrete implementations
>    outside of Lift.  We moved Box there because Box is richer than Scala's
>    Option class and being able to carry Exceptions around in a Box while still
>    being able to map/flatMap/foreach over a Box (these are unavailable for
>    Scala's Either).  Some we're going to actively promote using Box as a
>    replacement for Option in all Scala apps.  What this means for you is you
>    have to import net.liftweb.common._ in any file that you also import
>    net.liftweb.util.?

>    - Lift no longer support Scala Actors for Comet Actors.  The GenericActor

>    API offers pretty much the same client interface to Lift's Actors, so ! and
>    !? work the same way.  However, there's no link, self, start or exit
>    methods.
>
> Please do an "mvn -U clean install" on your code and run it against the new
> code.  If you have any Comet-related weirdness, please report it
> immediately.  We're planning M7 in 2 weeks, so we've got lots of time to
> iron any kinks out of this code.
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

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

[Jim Barrows]

RrttrRrrrrrrrtrtrtrrrtrtrrrrrrrrrtrrttÞ
Sent on the Now Network™ from my Sprint® BlackBerry

[David Pollak]

On Thu, Oct 22, 2009 at 6:28 PM, Jim Barrows <jim.b...@gmail.com> wrote:

RrttrRrrrrrrrtrtrtrrrtrtrrrrrrrrrtrrttÞ

bless you.

--

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

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

[David Pollak]

On Thu, Oct 22, 2009 at 6:03 PM, ssid <j.ga...@googlemail.com> wrote:

Hi all,
I'm using XMPP in my little LiftApp and tried to migrate my code to
the new Lift Actors.
Somehow it seems that net.liftweb.xmpp still uses Scala Actors.
Is this intentional or about to change?

I was lazy and didn't make that change.  I guess I should move the XMPP stuff over.

--

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

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

[Jonathan Ferguson]

If we are using Actors for non Comet based stuff I assume we are free to leave them as is as long as we don't come asking for support ? 

I am thinking about moving through switching them over, but I'd like to do it at a leisurely pace.

Jono

2009/10/23 David Pollak <feeder.of...@gmail.com>

[David Pollak]

On Thu, Oct 22, 2009 at 8:54 PM, Jonathan Ferguson <jo...@spiralarm.com> wrote:

If we are using Actors for non Comet based stuff I assume we are free to leave them as is as long as we don't come asking for support ? 

Absolutely.  Use the Actor library that best suits your needs.