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
Br's,
Marius
On Dec 31, 6:22 pm, Marius <marius.dan...@gmail.com> 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 <marius.dan...@gmail.com> 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 <dri...@gmail.com> 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 <timo...@getintheloop.eu> 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 <marius.dan...@gmail.com> 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 <timo...@getintheloop.eu>
> > > >>>> 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 lift...@googlegroups.com.
> > > >>> To unsubscribe from this group, send email to
> > > >>> liftweb+unsubscr...@googlegroups.com
> > > >>> .
> > > >>> 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 lift...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > liftweb+unsubscr...@googlegroups.com
> > > > .
> > > > 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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
