LiftSession is created with the contextPath that container provides.
See LiftRules._getLiftSession

However LiftSession.contextPath is defined as:

def contextPath = (LiftRules.calcContextPath(this) or
S.curRequestContextPath) openOr _contextPath

thus can you try it by setting in boot:

LiftRules.calculateContextPath = {req => Empty} ?

that should get you the contexPath the same as S. BT S.contextPath is
defined as:

def contextPath: String = session.map(_.contextPath) openOr ""

which essentially takes is from LiftSession.


Br's,
Marius

On Dec 31, 5:41 pm, Ross Mellgren <[email protected]> wrote:
> The problem I experienced with X-Lift-ContextPath is that it does not  
> set LiftSession.contextPath, which is where the AJAX path is generated  
> from. It set Req.contextPath, but not the session.
>
> I found this by using an nginx with this config:
>
>          location /foobar {
>               rewrite ^/foobar(.*)$ $1 break;
>               proxy_passhttp://127.0.0.1:8080;
>               proxy_set_header X-Lift-ContextPath "foobar";
>          }
>
> Pointing at a lift-archetype-basic with the hello world snippet  
> replaced by:
>
>    def howdy(in: NodeSeq): NodeSeq =
>        <div>Request contextPath = { S.request.map(_.contextPath)  
> openOr "unkwn" }</div> ++
>        <div>Session contextPath = { S.session.map(_.contextPath)  
> openOr "unkwn" }</div>
>
> With jetty configured at the default (contextPath at root), the output  
> is:
>
> Welcome to your project!
>
> Request contextPath = foobar
> Session contextPath =
>
> It looks like there is a LiftRules method intended to let you set the  
> session context path separately -- LiftRules.calcContextPath -- but it  
> is a val and not a RulesSeq or anything mutable.
>
> -Ross
>
> On Dec 31, 2009, at 10:28 AM, Marius wrote:
>
> > No I don't think so. But one can deploy the same application multiple
> > times with different context-paths .... as different copies. Sure it
> > is not ideal but I do not think lift misbehaves when it comes to JEE
> > contextpath.
>
> > Maybe I misunderstood the problem ... so I need to ask: Do people want
> > to deploy the same application (say the same war not separate copies)
> > under multiple context paths? If so then AFAIK this is a limitation on
> > JEE containers but one that can be worked around at framework level.
> > Is this the problem ?
>
> > Defect 68 is not 100% clear to me if it is the same with what I
> > described here or something else.
>
> > Br's,
> > Marius
>
> > On Dec 31, 3:57 pm, Timothy Perrett <[email protected]> wrote:
> >> Hey Marius,
>
> >> Is there a way to specify this argument on the command line? That  
> >> is, to tell jetty to use a particular jetty-web.xml ?
>
> >> Cheers, Tim
>
> >> On 31 Dec 2009, at 12:51, Marius wrote:
>
> >>> Ok I just tried a demo app I have and set the contextpath to /
> >>> mycontext in from pom.xml since I run the app as mvn jetty:run
>
> >>>                    <plugin>
> >>>                            <groupId>org.mortbay.jetty</groupId>
> >>>                            <artifactId>maven-jetty-plugin</
> >>> artifactId>
> >>>                            <configuration>
> >>>                                    <contextPath>/mycontext</
> >>> contextPath>
> >>>                                    <scanIntervalSeconds>5</
> >>> scanIntervalSeconds>
> >>>                            </configuration>
> >>>                    </plugin>
>
> >>> Note that this pom setting will override the contextpath setting  
> >>> that
> >>> you may have in WEB-INF/jetty-web.xml
>
> >>> With my test the cotnext path was used correctly .. so if you can  
> >>> put
> >>> together that small app I requested would be helpful.
>
> >>> Br's,
> >>> Marius
>
> >>> On Dec 31, 2:37 pm, Marius <[email protected]> wrote:
> >>>> Are you setting the context path in jetty web config? ...
> >>>> By default lift is using X-Lift-ContextPath header to determine the
> >>>> context path. Do you have this header? ... If it's not found Lift  
> >>>> uses
> >>>> the context path provided by the container.
>
> >>>> I have used before other context path-s with no problem. I  
> >>>> configured
> >>>> jetty using jetty-web.xml:
>
> >>>> <Configure class="org.mortbay.jetty.webapp.WebAppContext">
> >>>>     <Set name="contextPath" type="String">/mycontext</Set>
> >>>> </Configure>
>
> >>>> contextPath it used when referencing liftAjax.js ... it is used
> >>>> everywhere in Lift. Are you sure you set the application context  
> >>>> path
> >>>> correctly?
>
> >>>> Can you make a minimalistic Lift app, that I can just run, showing
> >>>> that context path is not used correctly by Lift? ... If you do I'll
> >>>> start working on it.
>
> >>>> Br's,
> >>>> Marius
>
> >>>> On Dec 31, 1:20 am, Timothy Perrett <[email protected]>  
> >>>> wrote:
>
> >>>>> Guys,
>
> >>>>> Im having a really strange problem with the context handling in  
> >>>>> an app
> >>>>> im writing. Essentially, the app is pretty "normal", it goes  
> >>>>> about its
> >>>>> business perfectly well. However, as this will be distributed  
> >>>>> through
> >>>>> different parts of our company, and could be deployed in different
> >>>>> contexts, I need a way of handling this. Our usual setup for  
> >>>>> apps is
> >>>>> to have them running as the root context on their own port and  
> >>>>> then to
> >>>>> manage app URIs through a front end proxy (yes, there are pros and
> >>>>> cons here, but it is what it is!)
>
> >>>>> For example, I want to deploy  the app to:
>
> >>>>> /mypath/<appurls>
>
> >>>>> whilst the guys in the USA might want to put it at:
>
> >>>>> /another/path/<appurls>
>
> >>>>> This is pretty problematic, as lift doesnt know about this and  
> >>>>> tries
> >>>>> to submit forms from the / context and also references liftAjax.js
> >>>>> from the root context too.
>
> >>>>> I've had a play with LiftRules.calculateContextPath but it doesn't
> >>>>> appear to do what I want, or im not understand how it should work.
>
> >>>>> Any ideas?
>
> >>>>> Cheers, Tim
>
> >>> --
>
> >>> You received this message because you are subscribed to the Google  
> >>> Groups "Lift" group.
> >>> To post to this group, send email to [email protected].
> >>> To unsubscribe from this group, send email to 
> >>> [email protected]
> >>> .
> >>> For more options, visit this group 
> >>> athttp://groups.google.com/group/liftweb?hl=en
> >>> .
>
> > --
>
> > You received this message because you are subscribed to the Google  
> > Groups "Lift" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to 
> > [email protected]
> > .
> > For more options, visit this group 
> > athttp://groups.google.com/group/liftweb?hl=en
> > .

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.


Reply via email to