On Dec 31, 2009, at 11:39 AM, Marius 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.
Agreed and agreed. I've tripped on calcContextPath before and then
realized it was val for some reason.
The only problem I thought of when I was thinking about this earlier
is that LiftSession.contextPath can be calculated in the absence of an
obvious Req (which is presumably why LiftRules.calcContextPath takes
LiftSession, versus calculateContextPath that takes HTTPRequest?).
Would you solve it by just making it use S.request? I'm asking more
for my own curiosity than anything else.
-Ross
> 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
> .
>
>
--
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.
