While working on clustering concerns, I discovered that out of the box Lift only provides a handful of ContainerSerializer instances. When I went to change some of the Lift squeryl module's SessionVars to ContainerVars, I quickly discovered compilation failures such as the following:
[error] /Users/joescii/Documents/code/oss/squeryl-auth-module/src/main/scala/net/liftmodules/squerylauth/AuthUser.scala:58: could not find implicit value for parameter containerSerializer: net.liftweb.http.ContainerSerializer[net.liftweb.common.Box[String]]
[error] private object curUserId extends ContainerVar[Box[String]](Empty)
[error]
There is
only one instance of ContainerSerializer provided. It's the default java serialization, so it works for any object which itself and all references implement java.io.Serializable. But because Box[String] isn't one of the types in the companion object, we get the above compilation failure.
I am about to open a PR which
adds a ContainerSeriazlier[T <: Serializable]. This will be what the developer wants 99% of the time. In the event that this particular serializer fails, it's always possible to provide a different one.
I suppose this was originally designed the way it is because all of the provided serializers are guaranteed to work at run time. The one I'm proposing can never make such a guarantee, because an object can implement Serializable but hold a reference to something which doesn't. Hence in general, it's not possible to check for
java.io serializability at compile time.
Even though this loses compile-time guarantees, I think it's better than failing to compile when the needed code is already provided, just not typed appropriately.
Any thoughts/concerns?
Joe