Just to continue this thread, Marius has done some great work, and its on review board.... i just tried it with my app and its working super duper; it appears the context handling was a bit screwed before.
Marius, kudos - as always, your fast turn around is awesome and greatly appreciated. Cheers, Tim On Dec 31 2009, 6:20 pm, Timothy Perrett <[email protected]> wrote: > Ok sounds like we are making progress - the behaviour Ross details is > indeed correct and what I want. > > Marius, by cleaning this up, do you think I can get the behaviour I > want? If so, when can this find its way into master? ;-) > > Cheers, Tim > > On Dec 31, 5:28 pm, Marius <[email protected]> wrote: > > > > > Sure thing ! > > > Br's, > > Marius > > > On Dec 31, 7:19 pm, David Pollak <[email protected]> > > wrote: > > > > 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 > > ... > > read more » -- 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.
