First of all I took the liberty of doing some changes ... some of them being breaking changes. Conceptually I see the LiftRules.calculateContextPath as a way for applications to specify the context path from their own config files or some other logic such as system variables. The value of the context path is typically an environment setting rather then a quantity that should change per request/session. Therefore LiftRules.calculateContextPath doesn't take the request parameter any more. But there is another reason for this change: ... for instance the default implementation was looking for X-Lift-ContextPath HTTP header attribute. However this lead to inconsistencies such that if a comet actor is generating some markup containing links etc. Lift could not fix those urls to add the contextpath since at this point lift doesn't have the request in order to extract the header information. Thus those links were "corrupted". 

Users could still implement LiftRules.calculateContextPath and inside use S but on their own risks as not always S is available when LiftRules.calculateContextPath is invoked. Therefore in order to be safe with contextpath, the contextpath should not be determined based on the request information and should be encouraged to be invariant or a global setting per application deployment. And I think this is the very point of the contextpath.

If you feel different, please elaborate and let's see what the use-cases are.

Br's,
Marius

Yes by setting:

LiftRules.calculateContextPath = () => {
  Full("/myapp")
}

and having JEE container contextPath as "/"