That doesn't work with the setup I described (which I think is what
Tim wants to do, but he should confirm or deny).
Here's the web page output:
Welcome to your project!
Request contextPath =
Session contextPath =
And the paths generated:
<script type="text/javascript" src="/ajax_request/liftAjax.js"></
script>
Note that the Jetty container doesn't know about the context path in
this case, it's running as root context (the default).
If I change <contextPath> to /foobar and tweak my nginx config:
Then I get the expected result:
Welcome to your project!
Request contextPath = /foobar
Session contextPath = /foobar
But I can't figure a way to make X-Lift-ContextPath useful, which
seems pretty useful (and encouraged?) for letting you drive all this
stuff from the proxy side.
As usual, I don't have the use case here, I'm just trying to help out
with some testing, so maybe this is sufficient for Tim.
I did a test last night which (seriously ab-)used some LiftRules PFs
to set S.curRequestContextPath to the same as Req.contextPath early in
the request cycle, and that made X-Lift-ContextPath work. I won't post
this to the list because it's a highly embarrassing hack ;-)
-Ross
On Dec 31, 2009, at 11:14 AM, Marius 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
> .
>
>
--
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.
