Im not sure it is; I do not require session by session adjustments... this is a one time, global configuration. Its similar, but not the same I dont think
I need this urgently in a production application that needs to go out yesterday (literally) so would appreciate any thoughts. Cheers, Tim On Dec 30, 11:26 pm, Ross Mellgren <[email protected]> wrote: > This is the same issue mentioned in the "Postmortem thoughts" thread, > that dpp mentioned has an issue > athttp://github.com/dpp/liftweb/issues#issue/68 > , right? > > On Dec 30, 2009, at 4:16 PM, David Pollak wrote: > > > > > > > Lift doesn't seem to have any central place to handle URL issues > > related to servlet context paths and domains / subdomains. We're > > currently running lift as a root servlet to avoid forcing context path > > to be visible in urls; this is fine for us but I can see it being > > useful for lift to know that the frontend proxy is taking care of > > mapping foo.com/ to the context /foo-lift-app/, instead of always > > adding the context path to urls. Similarly, we're running multiple > > subdomains from a single lift instance, because it's all basically > > common code and templates. The way we ended up making this work was > > to have 1 folder per subdomain, and subclass Link so that it knows how > > to createLink correctly based on headers the frontend is sending; e.g. > > the link forhttp://foo.bar.com/bazis put into the sitemap as / > > foo.bar/baz and will be rendered as /baz if the request is already in > > the foo subdomain, or fully qualifiedhttp://foo.bar.com/baz > > otherwise. In one sense, it was nice that we were even able to do > > this without modifying Lift. However, we already ran into the issue > > of default form redirects wanting to go to /foo.bar/baz, not just / > > baz, and there doesnt seem to be a clean place to handle that. > > > Yeah. I agree this is a problem. I opened a ticket on it forever > > ago:http://github.com/dpp/liftweb/issues#issue/68 > > > If you have any thoughts on how to deal with this, input would help > > formulate a solution. > > Just wanted to bring together the conversations, if they are the same > topic. > > -Ross > > On Dec 30, 2009, at 6:20 PM, Timothy Perrett 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 at http://groups.google.com/group/liftweb?hl=en.
