Also Req.context path is defined as: val contextPath = LiftRules.calculateContextPath(request) openOr request.contextPath
Br's, Marius On Dec 31, 6:14 pm, Marius <[email protected]> wrote: > 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.
