On Thu, Dec 31, 2009 at 8:39 AM, Marius <[email protected]> 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. > > 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 > Yeah... there should be just one. Thanks for volunteering to clean this one up. > > 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]<liftweb%[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]<liftweb%[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]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- 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.
