On Dec 31, 6:47 pm, Ross Mellgren <[email protected]> wrote: > On Dec 31, 2009, at 11:39 AM, Marius wrote: > > > OOOOOkkkk I think I know what the problem is: > > > We have both: > > > LiftRules.calcContextPath ... used by LiftSession.contextpath > > > AND > > > LiftRules.calculateContextPath ... used by Req.contextPath > > > which leads to confusing behavior. IMO this is a very confusing API > > and I think calcContextPath should go away. There should be a single > > point where the user can specify how the contextPath is calculated. > > Agreed and agreed. I've tripped on calcContextPath before and then > realized it was val for some reason. > > The only problem I thought of when I was thinking about this earlier > is that LiftSession.contextPath can be calculated in the absence of an > obvious Req (which is presumably why LiftRules.calcContextPath takes > LiftSession, versus calculateContextPath that takes HTTPRequest?). > Would you solve it by just making it use S.request? I'm asking more > for my own curiosity than anything else.
Not sure, it might be the case. However when we construct a LiftSession we provide the contextPath from the request and that is retained in the LiftSession, meaning that the contextPath can be safely obtained even if a request is not around ... say from a CometActor. > > -Ross > > > Dave, I'm not sure why we keep them both but let me know if you have > > some reasons for keeping them both. Otherwise I'll work on a fix in > > the next days > > > Br's, > > Marius > > > On Dec 31, 6:22 pm, Marius <[email protected]> wrote: > >> 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 > > 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.
