score:0

you could also use the produce directive. it allows you to decouple the actual marshalling from the request completion:

get {
  produce(instanceof[person]) { personcompleter =>
    databaseactor ! showpersonjob(personcompleter)
  }
}

the produce directive in this example extracts a function person => unit that you can use to complete the request transparently deep within the business logic layer, which should not be aware of spray.

https://github.com/spray/spray/wiki/marshalling-unmarshalling

score:3

in regards to your first question, yes, you are on the right track. (although i would also like to see some alternative ways to handle this sort of issue).

one suggestion i have is to insulate the persister actor from knowing about requests at all. you can pass the request as an any type. your matcher in your service code can automagically cast the cookie back into a request.

case class schedulepersisted(businessobjectid: string, cookie: any)

// in your actor
override def receive = super.receive orelse {
  case schedulepersisted(businessobjectid, request: request) =>
    request.complete("/businessobject/%s".format(businessobjectid))
}

in regards to your second question, actor classes are really no different than regular classes. but you do need to make sure you call the superclass's receive method, so that it can handle its own messages. i had some other ways of doing this in my original answer, but i think i prefer chaining partial functions like this:

class specialhttpservice extends httpservice {
  override def receive = super.receive orelse {
    case specialmessage(x) =>
      // handle special message
  }
}

Related Query

More Query from same tag