Thanks Tim but first let's see if the board approves the changes :)
Br's,
Marius
On Jan 2, 1:15 am, Timothy Perrett wrote:
> 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 cont
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
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 wrote:
> Sure thing !
>
> Br'
Sure thing !
Br's,
Marius
On Dec 31, 7:19 pm, David Pollak
wrote:
> On Thu, Dec 31, 2009 at 8:39 AM, Marius wrote:
> > O I think I know what the problem is:
>
> > We have both:
>
> > LiftRules.calcContextPath ... used by LiftSession.contextpath
>
> > AND
>
> > LiftRules.calculateContext
On Thu, Dec 31, 2009 at 8:39 AM, Marius wrote:
> O 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
On Dec 31, 2009, at 11:55 AM, Marius wrote:
> On Dec 31, 6:47 pm, Ross Mellgren wrote:
>> On Dec 31, 2009, at 11:39 AM, Marius wrote:
>> 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 Re
On Dec 31, 6:47 pm, Ross Mellgren wrote:
> On Dec 31, 2009, at 11:39 AM, Marius wrote:
>
> > O I think I know what the problem is:
>
> > We have both:
>
> > LiftRules.calcContextPath ... used by LiftSession.contextpath
>
> > AND
>
> > LiftRules.calculateContextPath ... used by Req.context
On Dec 31, 2009, at 11:39 AM, Marius wrote:
> O 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
O 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 awa
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:
Note that the Jetty container doesn't know about
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 wrote:
> LiftSession is created with the contextPath that container provides.
> See LiftRules._getLiftSession
>
> However LiftSession
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.
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 ^/
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 dep
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
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
org.mortbay.jetty
maven-jetty-plugin
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.
Dang.
What sort of test cases did you have in mind? Things that i've come across so
far are:
* form handling (normal forms, not ajax forms) - that is, the location of
action targets
* liftAjax.js - the path needs the context prepended
* Any dispatching needs the context accounted for
Is this
On Wed, Dec 30, 2009 at 3:36 PM, Timothy Perrett wrote:
> 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
> yeste
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
20 matches
Mail list logo
