[Lift] Indentation problem with Eclipse plugin
Hello guys, I am having a very strange indentation problem with the Eclipse plugin. To appreciate please maximize your email window. You can see how the second line starts after the last [ . It does it whenever you have [ ] in the code. object entries extends MappedOneToMany(FeedEntry, FeedEntry.entrySource) with Owned[FeedEntry] with Cascade[FeedEntry] object tribes extends MappedManyToMany(ContentTribes, ContentTribes.sourceId, ContentTribes.tribeId, Tribe) I was trying to live with it, but it is kind of annoying in long chunks of code. Any ideas on how to solve it? Thanks in advance and happy 2010 to everybody. Cheers, GA -- 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.
[Lift] Re: Nice 404s sans Redirect
You could put a Script tag and inside set the title via JavaScript?
But I'm still working on the solution I proposed which treats 404 as a
normal page. Not sure if Dave will like it (probably not) but I'll
send him a diff.
Br's,
Marius
On Dec 31, 5:43 am, Alex Black a...@alexblack.ca wrote:
Ok, I tried this, it gets closer.
I noticed one issue: the head merge didn't get done, so I have two
head tags in the result. I'm attempting to set the title in the
404.html template, maybe there is a way I can set the title without
using head merge?
- Alex
On Dec 30, 2:54 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
In Boot.scala (the boot method):
LiftRules.passNotFoundToChain = false
LiftRules.uriNotFound.prepend {
case _ = generate404()
}
In the Boot class:
def generate404(): LiftResponse = {
import scala.xml.Node
val resp: Box[Node] = S.setVars(expandAll - true) {
for {
rendered - S.runTemplate(404 :: Nil)
} yield rendered(0)
}
XhtmlResponse(resp openOr htmlbodyGot a 404/body/html,
Empty, List(Content-Type - text/html; charset=utf-8),
Nil, 404, S.ieMode)
}
And a 404.html file (which can be localized):
lift:surround with=default at=content
Couldn't find your page... sorry
/lift:surround
The uriNotFound code is executed within the S scope, so you've got all the
goodness of knowing who the current user is, etc.
The reason that the menu was not being rendered in your example is that menu
rendering is based on the location property in the Req(uest). If there is
no location (as defined in the SiteMap), then no menu can be rendered.
There's an option for displaying the entire sitemap by setting the
expandAll=true attribute when invoking the Menu.builder snippet. But you
don't really want to show the entire menu on all pages, so the
S.setVars(expandAll - true) {...} method (which is a good candidate for
renaming for all you renamers out there) allows us to set the expandAll
attribute for the duration of the code block.
Then we use S.runTemplate() to locate and run the 404.html template.
Finally, we create the XhtmlResponse with the 404 error code.
So, you can put whatever you want in the 404.html template (including
snippets) and all will work as expected.
Thanks,
David
On Wed, Dec 30, 2009 at 10:45 AM, Alex Black a...@alexblack.ca wrote:
It's not rewriting.
I didn't say it was. I just said it seemed most similar to re-writing.
Trying to mix the two will muddy the concept of rewriting and when it
happens.
Makes sense.
As far as I can tell, the two problems you are facing are:
1. There's a non-trivial amount of your code that needs to run to
render
the 404 error page. This would be corrected by the suggestion that I
posted
regarding a LiftRule that generates the default 404 template.
2. Putting navigation on the page. I'm still noodling how to address
this particular issue.
If there are issues other than 1 and 2, please enumerate them.
Those do sound like the issues. Just to reflect it back to you from
my perspective (in case one of us is missing something), the issue as
I see it is that I've designed a nice 404 template using lift features
(like surround, sitemap, headmerge), and I'd like to display it to the
user when no handler can be found
Whats preventing me from doing this is: the current notfound mechanism
takes a liftResponse, not a template to render, and as such forces me
to render the template itself, and although Russ proposed a way to do
that Marius indicated this could have side effects and feels like the
wrong approach.
What about Either[RewriteResponse, LiftResponse]? E.g. same as what
Marius suggested but use RewriteResponse instead of String.
On Dec 30, 1:26 pm, Marius marius.dan...@gmail.com wrote:
I thought of that but that is problematic because:
1. Having a TemplateResponse holding a path without the rendering
logic, people could use that to send a response to the client, which
would be incorrect as having a LiftResponse holding /a/b/c doesn;t
mean anything to a client. And this would alter the semantics of a
LiftResponse. That's why I proposed an Either.
2. On the other hand if we have a TemplateResponse holding the logic
of processing a template (similar to the one proposed on this
thread)
would mean that we're doing the processing outside of the normal
rendering pipeline which has the downsides discussed.
Br's,
Marius
On Dec 30, 8:18 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Would it not be possible to have a LiftResponse that runs through
the
regular plumbing? This way instead of introducing Either you can just
use a
TemplateResponse etc.
Re: [Lift] Indentation problem with Eclipse plugin
As this is a problem with the eclipse plugin, you'll get a better / right response on either scala-user or logging an issue with epfl trac so miles can pick it up and address it. Cheers, Tim On 31 Dec 2009, at 08:40, GA wrote: Hello guys, I am having a very strange indentation problem with the Eclipse plugin. To appreciate please maximize your email window. You can see how the second line starts after the last [ . It does it whenever you have [ ] in the code. object entries extends MappedOneToMany(FeedEntry, FeedEntry.entrySource) with Owned[FeedEntry] with Cascade[FeedEntry] object tribes extends MappedManyToMany(ContentTribes, ContentTribes.sourceId, ContentTribes.tribeId, Tribe) I was trying to live with it, but it is kind of annoying in long chunks of code. Any ideas on how to solve it? Thanks in advance and happy 2010 to everybody. Cheers, GA -- 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.
Re: [Lift] Indentation problem with Eclipse plugin
On Thu, Dec 31, 2009 at 11:11 AM, Timothy Perrett timo...@getintheloop.eu wrote: As this is a problem with the eclipse plugin, you'll get a better / right response on either scala-user or logging an issue with epfl trac so miles can pick it up and address it. No need ... this is fixed on trunk. Cheers, Miles -- Miles Sabin tel: +44 (0)7813 944 528 skype: milessabin http://www.chuusai.com/ http://twitter.com/milessabin -- 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.
[Lift] Re: Issue with Context Handling
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 at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Indentation problem with Eclipse plugin
Thanks for the answers. Good to know that it has been fixed already on trunk. Any idea when the new release of the plugin will be available? Cheers, GA On Dec 31, 2009, at 1:12 PM, Miles Sabin wrote: On Thu, Dec 31, 2009 at 11:11 AM, Timothy Perrett timo...@getintheloop.eu wrote: As this is a problem with the eclipse plugin, you'll get a better / right response on either scala-user or logging an issue with epfl trac so miles can pick it up and address it. No need ... this is fixed on trunk. Cheers, Miles -- Miles Sabin tel: +44 (0)7813 944 528 skype: milessabin http://www.chuusai.com/ http://twitter.com/milessabin -- 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.
[Lift] Re: Issue with Context Handling
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 groupIdorg.mortbay.jetty/groupId artifactIdmaven-jetty-plugin/artifactId configuration contextPath/mycontext/contextPath scanIntervalSeconds5/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 at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Indentation problem with Eclipse plugin
On Thu, Dec 31, 2009 at 12:45 PM, GA my_li...@me.com wrote: Thanks for the answers. Good to know that it has been fixed already on trunk. Any idea when the new release of the plugin will be available? Simultaneously with the first (real, rather than beta) release candidate of scala 2.8.0. Cheers, Miles -- Miles Sabin tel: +44 (0)7813 944 528 skype: milessabin http://www.chuusai.com/ http://twitter.com/milessabin -- 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.
Re: [Lift] Re: Issue with Context Handling
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 groupIdorg.mortbay.jetty/groupId artifactIdmaven-jetty-plugin/artifactId configuration contextPath/mycontext/contextPath scanIntervalSeconds5/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 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.
[Lift] Re: Issue with Context Handling
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 groupIdorg.mortbay.jetty/groupId artifactIdmaven-jetty-plugin/artifactId configuration contextPath/mycontext/contextPath scanIntervalSeconds5/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 at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Issue with Context Handling
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_pass http://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 =
divRequest contextPath = { S.request.map(_.contextPath)
openOr unkwn }/div ++
divSession 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
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/
artifactId
configuration
contextPath/mycontext/
contextPath
scanIntervalSeconds5/
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
[Lift] Re: Issue with Context Handling
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 =
divRequest contextPath = { S.request.map(_.contextPath)
openOr unkwn }/div ++
divSession 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
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/
artifactId
configuration
contextPath/mycontext/
contextPath
scanIntervalSeconds5/
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
[Lift] Re: DB problems on Jetty restart
Thanks, that cleared up the problem. It even pointed out
LiftRules.unloadHooks which answered my second question.
On Dec 31, 12:33 am, joseph hirn joseph.h...@gmail.com wrote:
Yes I had an open thread on this issue but it's not being seen as a
real issue.
http://groups.google.com/group/liftweb/browse_thread/thread/78454f767...
On Dec 30, 7:15 pm, Nathan Parry npa...@gmail.com wrote:
Searching turned up a few older threads similar to the problem I'm
seeing, but I couldn't find any solution.
Using just the skeleton project created by lift-archetype-basic, I'm
getting these exceptions out of jetty:
org.h2.jdbc.JdbcSQLException: Database may be already in use: Locked
by another process. Possible solutions: close all other connection(s);
use the server mode [90020-121]
ERROR - Failed to Boot
java.lang.NullPointerException: Looking for Connection Identifier
ConnectionIdentifier(lift) but failed to find either a JNDI data
source with the name lift or a lift connection manager with the
correct name
Once this happens, the app is non-functional. This occurs whenever
jetty restarts due to updated code. I can trigger the issue by:
1. Running mvn jetty:run in one console
2. Running mvn scala:cc in another console
3. Running touch src/main/scala/bootstrap/liftweb/Boot.scala in a 3rd
console
This causes a recompilation, which causes a jetty restart, which blows
up with the exceptions.
Has anybody else seen or fixed this issue? Should it be useful, I've
stashed the project
athttp://nparry.com/posted_files/jetty_lift_issues/lifttest.tgz
including a jetty.log of the output with the full stack traces.
Wandering into wild-speculation territory (AKA speak and remove all
doubt) ...
Based on the jdbc exception, I poked around in the DB code - looking
at ProtoDBVendor I couldn't see how connections in 'pool' would ever
be released. Thus I tried a quick hack in my project to force the
pool to be empty...
DB.defineConnectionManager(DefaultConnectionIdentifier,
new StandardDBVendor(
Props.get(db.driver) openOr
org.h2.Driver,
Props.get(db.url) openOr
jdbc:h2:lift_proto.db,
Props.get(db.user),
Props.get(db.password)) {
override def maxPoolSize = 0
})
This obviously is not a good solution, but it does seem to clear up
the exceptions when jetty restarts - the theory being that during
shutdown the old connections are not closed, leading to errors during
restart since the new connection can't be created. Forcing an empty
pool means there is no old connection around to trigger the problem.
I guess the question out of all that would be - do we need (or is
there already) a shutdown hook to correspond to the boot hook? This
would allow for cleanup in this sort of situation (ie, close any
connections left in the pool).
--
Nathan
--
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.
[Lift] Re: Issue with Context Handling
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 =
divRequest contextPath = { S.request.map(_.contextPath)
openOr unkwn }/div ++
divSession 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
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/
artifactId
configuration
contextPath/mycontext/
contextPath
scanIntervalSeconds5/
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
Re: [Lift] Re: Issue with Context Handling
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 =
divRequest contextPath = { S.request.map(_.contextPath)
openOr unkwn }/div ++
divSession 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
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/
artifactId
configuration
contextPath/mycontext/
contextPath
scanIntervalSeconds5/
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
[Lift] Re: Issue with Context Handling
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 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 =
divRequest contextPath = { S.request.map(_.contextPath)
openOr unkwn }/div ++
divSession 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
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/
artifactId
configuration
contextPath/mycontext/
contextPath
scanIntervalSeconds5/
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
Re: [Lift] Re: Issue with Context Handling
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 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 =
divRequest contextPath = { S.request.map(_.contextPath)
openOr unkwn }/div ++
divSession 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
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/
artifactId
configuration
contextPath/mycontext/
contextPath
scanIntervalSeconds5/
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
[Lift] Re: Issue with Context Handling
On Dec 31, 6:47 pm, Ross Mellgren dri...@gmail.com 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.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.
Not sure, it might be the case. However when we construct a
LiftSession we provide the contextPath from the request and that is
retained in the LiftSession, meaning that the contextPath can be
safely obtained even if a request is not around ... say from a
CometActor.
-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 =
divRequest contextPath = { S.request.map(_.contextPath)
openOr unkwn }/div ++
divSession 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
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/
artifactId
configuration
contextPath/mycontext/
contextPath
Re: [Lift] Re: Issue with Context Handling
On Dec 31, 2009, at 11:55 AM, Marius wrote: On Dec 31, 6:47 pm, Ross Mellgren dri...@gmail.com 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 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. Not sure, it might be the case. However when we construct a LiftSession we provide the contextPath from the request and that is retained in the LiftSession, meaning that the contextPath can be safely obtained even if a request is not around ... say from a CometActor. Thanks. I'm still trying to get a solid handle on how the Lift request processing pipeline works on the inside, every piece helps! -Ross -- 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.
Re: [Lift] Re: Issue with Context Handling
On Thu, Dec 31, 2009 at 8:39 AM, Marius marius.dan...@gmail.com 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 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
Yeah... there should be just one. Thanks for volunteering to clean this one
up.
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 =
divRequest contextPath = { S.request.map(_.contextPath)
openOr unkwn }/div ++
divSession 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
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/
artifactId
configuration
contextPath/mycontext/
contextPath
scanIntervalSeconds5/
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
[Lift] Re: Issue with Context Handling
Sure thing !
Br's,
Marius
On Dec 31, 7:19 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Thu, Dec 31, 2009 at 8:39 AM, Marius marius.dan...@gmail.com 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 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
Yeah... there should be just one. Thanks for volunteering to clean this one
up.
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 =
divRequest contextPath = { S.request.map(_.contextPath)
openOr unkwn }/div ++
divSession 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
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/
artifactId
configuration
contextPath/mycontext/
contextPath
scanIntervalSeconds5/
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,
[Lift] Re: [ANN] Lift 1.1-M8
Heiko,
I just tried runtime scope and I get the same exception when
recompiling a Scala file with jetty still running. Do you experience
the same?
org.h2.jdbc.JdbcSQLException: Database may be already in use: Locked
by another process. Possible solutions: close all other connection(s);
use the server mode [90020-121]
For production, when you are taking your warfile and deploying it
somewhere runtime may be suitable but for development, having Jetty be
able to hot redeploy is critical, at least to me. I can change it to
taste sure, but most people aren't experts in maven let alone maven-
jetty-plugin.
On Dec 31, 1:10 am, Heiko Seeberger heiko.seeber...@googlemail.com
wrote:
Hi,
What about using *runtime* scope for the database drivers? This is what I am
always changing my POM to. Because IMHO it is just the right thing: No
compilation dependency, but working with *mvn jetty:run* and inclusion in
the WAR.
By the way: The same applies to log4j.
This is a snippet from a production app:
dependencies
!-- compile --
dependency
groupIdnet.liftweb/groupId
artifactIdlift-webkit/artifactId
version${lift.version}/version
/dependency
dependency
groupIdnet.liftweb/groupId
artifactIdlift-mapper/artifactId
version${lift.version}/version
/dependency
!-- runtime --
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.14/version
scoperuntime/scope
/dependency
dependency
groupIdcom.h2database/groupId
artifactIdh2/artifactId
version1.2.121/version
scoperuntime/scope
/dependency
!-- test --
dependency
groupIdorg.scalatest/groupId
artifactIdscalatest/artifactId
version1.0/version
scopetest/scope
/dependency
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.5/version
scopetest/scope
/dependency
dependency
groupIdorg.mortbay.jetty/groupId
artifactIdjetty/artifactId
version[6.1.22,7)/version
scopetest/scope
/dependency
/dependencies
Just my 2 cent ...
Heiko
My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
--
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.
[Lift] Re: DB problems on Jetty restart
Glad I could help.
On Dec 31, 10:12 am, Nathan Parry npa...@gmail.com wrote:
Thanks, that cleared up the problem. It even pointed out
LiftRules.unloadHooks which answered my second question.
On Dec 31, 12:33 am, joseph hirn joseph.h...@gmail.com wrote:
Yes I had an open thread on this issue but it's not being seen as a
real issue.
http://groups.google.com/group/liftweb/browse_thread/thread/78454f767...
On Dec 30, 7:15 pm, Nathan Parry npa...@gmail.com wrote:
Searching turned up a few older threads similar to the problem I'm
seeing, but I couldn't find any solution.
Using just the skeleton project created by lift-archetype-basic, I'm
getting these exceptions out of jetty:
org.h2.jdbc.JdbcSQLException: Database may be already in use: Locked
by another process. Possible solutions: close all other connection(s);
use the server mode [90020-121]
ERROR - Failed to Boot
java.lang.NullPointerException: Looking for Connection Identifier
ConnectionIdentifier(lift) but failed to find either a JNDI data
source with the name lift or a lift connection manager with the
correct name
Once this happens, the app is non-functional. This occurs whenever
jetty restarts due to updated code. I can trigger the issue by:
1. Running mvn jetty:run in one console
2. Running mvn scala:cc in another console
3. Running touch src/main/scala/bootstrap/liftweb/Boot.scala in a 3rd
console
This causes a recompilation, which causes a jetty restart, which blows
up with the exceptions.
Has anybody else seen or fixed this issue? Should it be useful, I've
stashed the project
athttp://nparry.com/posted_files/jetty_lift_issues/lifttest.tgz
including a jetty.log of the output with the full stack traces.
Wandering into wild-speculation territory (AKA speak and remove all
doubt) ...
Based on the jdbc exception, I poked around in the DB code - looking
at ProtoDBVendor I couldn't see how connections in 'pool' would ever
be released. Thus I tried a quick hack in my project to force the
pool to be empty...
DB.defineConnectionManager(DefaultConnectionIdentifier,
new StandardDBVendor(
Props.get(db.driver) openOr
org.h2.Driver,
Props.get(db.url) openOr
jdbc:h2:lift_proto.db,
Props.get(db.user),
Props.get(db.password)) {
override def maxPoolSize = 0
})
This obviously is not a good solution, but it does seem to clear up
the exceptions when jetty restarts - the theory being that during
shutdown the old connections are not closed, leading to errors during
restart since the new connection can't be created. Forcing an empty
pool means there is no old connection around to trigger the problem.
I guess the question out of all that would be - do we need (or is
there already) a shutdown hook to correspond to the boot hook? This
would allow for cleanup in this sort of situation (ie, close any
connections left in the pool).
--
Nathan
--
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.
Re: [Lift] DB problems on Jetty restart
On Wed, Dec 30, 2009 at 5:15 PM, Nathan Parry npa...@gmail.com wrote:
Searching turned up a few older threads similar to the problem I'm
seeing, but I couldn't find any solution.
Using just the skeleton project created by lift-archetype-basic, I'm
getting these exceptions out of jetty:
org.h2.jdbc.JdbcSQLException: Database may be already in use: Locked
by another process. Possible solutions: close all other connection(s);
use the server mode [90020-121]
ERROR - Failed to Boot
java.lang.NullPointerException: Looking for Connection Identifier
ConnectionIdentifier(lift) but failed to find either a JNDI data
source with the name lift or a lift connection manager with the
correct name
Once this happens, the app is non-functional. This occurs whenever
jetty restarts due to updated code. I can trigger the issue by:
1. Running mvn jetty:run in one console
2. Running mvn scala:cc in another console
3. Running touch src/main/scala/bootstrap/liftweb/Boot.scala in a 3rd
console
Thanks for the repro case. I've opened a ticket on the issue:
http://github.com/dpp/liftweb/issues/#issue/266
This causes a recompilation, which causes a jetty restart, which blows
up with the exceptions.
Has anybody else seen or fixed this issue? Should it be useful, I've
stashed the project at
http://nparry.com/posted_files/jetty_lift_issues/lifttest.tgz
including a jetty.log of the output with the full stack traces.
Wandering into wild-speculation territory (AKA speak and remove all
doubt) ...
Based on the jdbc exception, I poked around in the DB code - looking
at ProtoDBVendor I couldn't see how connections in 'pool' would ever
be released. Thus I tried a quick hack in my project to force the
pool to be empty...
DB.defineConnectionManager(DefaultConnectionIdentifier,
new StandardDBVendor(
Props.get(db.driver) openOr
org.h2.Driver,
Props.get(db.url) openOr
jdbc:h2:lift_proto.db,
Props.get(db.user),
Props.get(db.password)) {
override def maxPoolSize = 0
})
This obviously is not a good solution, but it does seem to clear up
the exceptions when jetty restarts - the theory being that during
shutdown the old connections are not closed, leading to errors during
restart since the new connection can't be created. Forcing an empty
pool means there is no old connection around to trigger the problem.
I guess the question out of all that would be - do we need (or is
there already) a shutdown hook to correspond to the boot hook? This
would allow for cleanup in this sort of situation (ie, close any
connections left in the pool).
--
Nathan
--
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.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
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.
Re: [Lift] Re: Postmortem thoughts on a small production Lift site
On Wed, Dec 30, 2009 at 4:01 PM, Nathan npa...@gmail.com wrote: Jetty seems to do questionable things with filehandles, opening multiple copies of the same template file and keeping them open too long. Setting ulimit fixes the issue of Too many open files exceptions failed requests, but it still seems like at most templates should need 1 access to check mtime. Not really a lift issue, and not a deal breaker for us to switch to a different servlet container, but I am curious to see what the eventual solution for comet performance is. If you can put together a reproducible case on this, we'll see what we can do to close stuff that Jetty hands us more explicitly. I'm a total Lift and Scala newbie, but file-handle problems and last- modified checks remind me of this bug in Facelets: https://facelets.dev.java.net/issues/show_bug.cgi?id=278 Thanks. Looks like you found a defect and I've opened a defect. It looks like ResourceServer.scala may be hitting the same problem between the findResourceInClasspath and calcLastModified methods, but again - total newbie - so take that with a boulder sized grain of salt. -- Nathan -- 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- 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.
[Lift] Re: Issue with Context Handling
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 marius.dan...@gmail.com wrote:
Sure thing !
Br's,
Marius
On Dec 31, 7:19 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Thu, Dec 31, 2009 at 8:39 AM, Marius marius.dan...@gmail.com 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 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
Yeah... there should be just one. Thanks for volunteering to clean this one
up.
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 =
divRequest contextPath = { S.request.map(_.contextPath)
openOr unkwn }/div ++
divSession 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
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/
artifactId
configuration
contextPath/mycontext/
contextPath
scanIntervalSeconds5/
[Lift] Re: DB problems on Jetty restart
The simplest way around this issue is:
new StandardDBVendor(Props.get(db.driver) openOr org.h2.Driver,
Props.get(db.url) openOr
jdbc:h2:lift_proto.db;AUTO_SERVER=TRUE,
Props.get(db.user),
Props.get(db.password))
Note the ;AUTO_SERVER=TRUE part of the DB URL. This makes the H2
restart issue go away. There's an additional issue of ActorPing which
is not restarting correctly. I've got a fix for that as well and I'll
have the code up on review board in a little while.
On Dec 31, 10:13 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Wed, Dec 30, 2009 at 5:15 PM, Nathan Parry npa...@gmail.com wrote:
Searching turned up a few older threads similar to the problem I'm
seeing, but I couldn't find any solution.
Using just the skeleton project created by lift-archetype-basic, I'm
getting these exceptions out of jetty:
org.h2.jdbc.JdbcSQLException: Database may be already in use: Locked
by another process. Possible solutions: close all other connection(s);
use the server mode [90020-121]
ERROR - Failed to Boot
java.lang.NullPointerException: Looking for Connection Identifier
ConnectionIdentifier(lift) but failed to find either a JNDI data
source with the name lift or a lift connection manager with the
correct name
Once this happens, the app is non-functional. This occurs whenever
jetty restarts due to updated code. I can trigger the issue by:
1. Running mvn jetty:run in one console
2. Running mvn scala:cc in another console
3. Running touch src/main/scala/bootstrap/liftweb/Boot.scala in a 3rd
console
Thanks for the repro case. I've opened a ticket on the
issue:http://github.com/dpp/liftweb/issues/#issue/266
This causes a recompilation, which causes a jetty restart, which blows
up with the exceptions.
Has anybody else seen or fixed this issue? Should it be useful, I've
stashed the project at
http://nparry.com/posted_files/jetty_lift_issues/lifttest.tgz
including a jetty.log of the output with the full stack traces.
Wandering into wild-speculation territory (AKA speak and remove all
doubt) ...
Based on the jdbc exception, I poked around in the DB code - looking
at ProtoDBVendor I couldn't see how connections in 'pool' would ever
be released. Thus I tried a quick hack in my project to force the
pool to be empty...
DB.defineConnectionManager(DefaultConnectionIdentifier,
new StandardDBVendor(
Props.get(db.driver) openOr
org.h2.Driver,
Props.get(db.url) openOr
jdbc:h2:lift_proto.db,
Props.get(db.user),
Props.get(db.password)) {
override def maxPoolSize = 0
})
This obviously is not a good solution, but it does seem to clear up
the exceptions when jetty restarts - the theory being that during
shutdown the old connections are not closed, leading to errors during
restart since the new connection can't be created. Forcing an empty
pool means there is no old connection around to trigger the problem.
I guess the question out of all that would be - do we need (or is
there already) a shutdown hook to correspond to the boot hook? This
would allow for cleanup in this sort of situation (ie, close any
connections left in the pool).
--
Nathan
--
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.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Surf the harmonics
--
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.
[Lift] Re: DB problems on Jetty restart
Thanks for the quick turnaround!
On Dec 31, 1:41 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
The simplest way around this issue is:
new StandardDBVendor(Props.get(db.driver) openOr org.h2.Driver,
Props.get(db.url) openOr
jdbc:h2:lift_proto.db;AUTO_SERVER=TRUE,
Props.get(db.user),
Props.get(db.password))
Note the ;AUTO_SERVER=TRUE part of the DB URL. This makes the H2
restart issue go away. There's an additional issue of ActorPing which
is not restarting correctly. I've got a fix for that as well and I'll
have the code up on review board in a little while.
On Dec 31, 10:13 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Wed, Dec 30, 2009 at 5:15 PM, Nathan Parry npa...@gmail.com wrote:
Searching turned up a few older threads similar to the problem I'm
seeing, but I couldn't find any solution.
Using just the skeleton project created by lift-archetype-basic, I'm
getting these exceptions out of jetty:
org.h2.jdbc.JdbcSQLException: Database may be already in use: Locked
by another process. Possible solutions: close all other connection(s);
use the server mode [90020-121]
ERROR - Failed to Boot
java.lang.NullPointerException: Looking for Connection Identifier
ConnectionIdentifier(lift) but failed to find either a JNDI data
source with the name lift or a lift connection manager with the
correct name
Once this happens, the app is non-functional. This occurs whenever
jetty restarts due to updated code. I can trigger the issue by:
1. Running mvn jetty:run in one console
2. Running mvn scala:cc in another console
3. Running touch src/main/scala/bootstrap/liftweb/Boot.scala in a 3rd
console
Thanks for the repro case. I've opened a ticket on the
issue:http://github.com/dpp/liftweb/issues/#issue/266
This causes a recompilation, which causes a jetty restart, which blows
up with the exceptions.
Has anybody else seen or fixed this issue? Should it be useful, I've
stashed the project at
http://nparry.com/posted_files/jetty_lift_issues/lifttest.tgz
including a jetty.log of the output with the full stack traces.
Wandering into wild-speculation territory (AKA speak and remove all
doubt) ...
Based on the jdbc exception, I poked around in the DB code - looking
at ProtoDBVendor I couldn't see how connections in 'pool' would ever
be released. Thus I tried a quick hack in my project to force the
pool to be empty...
DB.defineConnectionManager(DefaultConnectionIdentifier,
new StandardDBVendor(
Props.get(db.driver) openOr
org.h2.Driver,
Props.get(db.url) openOr
jdbc:h2:lift_proto.db,
Props.get(db.user),
Props.get(db.password)) {
override def maxPoolSize = 0
})
This obviously is not a good solution, but it does seem to clear up
the exceptions when jetty restarts - the theory being that during
shutdown the old connections are not closed, leading to errors during
restart since the new connection can't be created. Forcing an empty
pool means there is no old connection around to trigger the problem.
I guess the question out of all that would be - do we need (or is
there already) a shutdown hook to correspond to the boot hook? This
would allow for cleanup in this sort of situation (ie, close any
connections left in the pool).
--
Nathan
--
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.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Surf the harmonics
--
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.
Re: [Lift] Re: Sitemap: Using instead of index and still having the current menu selected?
I was in SiteMap for another project today. I'll add a flag on the SiteMap object that facilitates / rather than /index. On Wed, Dec 30, 2009 at 7:47 PM, Alex Black a...@alexblack.ca wrote: Would it be reasonable for me to open a ticket to allow people to change this default behaviour? Its important to me that when people are at our site's home page, its just http://oursite.com;, not http://oursite.com/index;. Then for people who are using a container where this is a problem, it will work fine, but others can avoid the index in the url. - Alex On Dec 30, 12:49 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Dec 30, 2009 at 9:43 AM, Alex Black a...@alexblack.ca wrote: In a 1.1-M8 based project, http://localhost:8080/andhttp://localhost:8080/indexbothcause the Home menu item to be non-clickable. The definition of the Home menu item is Menu(Loc(Home, List(index), Home)) Understood. However, in this scenario, when the user clicks on home they get taken tohttp://localhost:8080/index, I think it would be even better if they could be taken tohttp://localhost:8080/. Its mostly aesthetic, but its cleaner/shorter, and it saves having two URLs for the same thing (e.g.http://localhost:8080/and http://localhost:8080/index). Is there any way to do that while maintaining the nice Sitemap feature that makes Home non clickable? As I said already, we had thehttp://localhost:8080/as the place where the top level takes you. That broke some containers (I don't remember the specifics) so the top level is /index. There's no way to change it and it is this way for the reason that I've now had to state twice in two days. - Alex Also, why do you using Pair(List(...), false)? Pair is deprecated/frowned on... it's much more idomatic to use (List(...), false), but that's not needed as there's an implicit conversion you can simply declare the List(). Thanks for the tip. to Menu(Loc(index, Pair( :: Nil, false), Home)) :: So that my Home link goes to mysite.com/ instead of mysite.com/ index. But, I notice, when you're at mysite.com/ the sitemap doesn't show Home as selected, is there a way to fix that? Perhaps I've got something wrong here. Thanks, - Alex -- 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.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com liftweb%252bunsubscr...@googlegroups.comliftweb%25252bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com liftweb%252bunsubscr...@googlegroups.comliftweb%25252bunsubscr...@googlegroups.com liftweb%252bunsubscr...@googlegroups.comliftweb%25252bunsubscr...@googlegroups.com liftweb%25252bunsubscr...@googlegroups.comliftweb%2525252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- 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.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com liftweb%252bunsubscr...@googlegroups.comliftweb%25252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- 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.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional
[Lift] cookie vs url sessionId precedence
Hi, I'm using a flash upload widget to post to a Lift mapped function (/ajax_request/name/;jsessionid=x). That works fine, but there is a bug in flash on windows where it decides to send over cookies which were created in IE regardless of what browser you are now using. This causes the JSESSIONID cookie to be sent to the server which is not associated with the current browser's session. That cookie seems to take precedence over the jsessionid in the URL which means that Lift does not find the function associated with the parameter. Is there a way to tell Lift, or Jetty, that jsessionid should take precedence? or is there a way to hook in very early in the request cycle to allow filtering out cookies from the request? Also, is there an easy way to wrap a url with the correct jsessionid parameter. Currently I'm doing it manually: ;jsessionid=+S.containerSession.map(_.sessionId).openOr(). That sort of works, but I've noticed that the url is missing .WorkerName piece of the sessionId that Jetty appends to do allow load balancing to work correctly. Thanks, Jon -- 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.
Re: [Lift] Re: Nice 404s sans Redirect
On Wed, Dec 30, 2009 at 7:43 PM, Alex Black a...@alexblack.ca wrote:
Ok, I tried this, it gets closer.
I noticed one issue: the head merge didn't get done, so I have two
head tags in the result. I'm attempting to set the title in the
404.html template, maybe there is a way I can set the title without
using head merge?
I'm opening up the merge method, so once the code is in master, you'll be
able to do:
def generate404(): LiftResponse = {
import scala.xml.Node
val resp: Box[Node] = S.setVars(expandAll - true) {
for {
session - S.session
req - S.request
rendered - S.runTemplate(404 :: Nil)
} yield session.performHeadMerge(rendered, req)
}
XhtmlResponse(resp openOr htmlbodyGot a 404/body/html,
Empty, List(Content-Type - text/html; charset=utf-8),
Nil, 404, S.ieMode)
}
This will do the head merge and give you the ability to do anything Lift
does.
- Alex
On Dec 30, 2:54 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
In Boot.scala (the boot method):
LiftRules.passNotFoundToChain = false
LiftRules.uriNotFound.prepend {
case _ = generate404()
}
In the Boot class:
def generate404(): LiftResponse = {
import scala.xml.Node
val resp: Box[Node] = S.setVars(expandAll - true) {
for {
rendered - S.runTemplate(404 :: Nil)
} yield rendered(0)
}
XhtmlResponse(resp openOr htmlbodyGot a 404/body/html,
Empty, List(Content-Type - text/html;
charset=utf-8),
Nil, 404, S.ieMode)
}
And a 404.html file (which can be localized):
lift:surround with=default at=content
Couldn't find your page... sorry
/lift:surround
The uriNotFound code is executed within the S scope, so you've got all
the
goodness of knowing who the current user is, etc.
The reason that the menu was not being rendered in your example is that
menu
rendering is based on the location property in the Req(uest). If there
is
no location (as defined in the SiteMap), then no menu can be rendered.
There's an option for displaying the entire sitemap by setting the
expandAll=true attribute when invoking the Menu.builder snippet. But
you
don't really want to show the entire menu on all pages, so the
S.setVars(expandAll - true) {...} method (which is a good candidate
for
renaming for all you renamers out there) allows us to set the expandAll
attribute for the duration of the code block.
Then we use S.runTemplate() to locate and run the 404.html template.
Finally, we create the XhtmlResponse with the 404 error code.
So, you can put whatever you want in the 404.html template (including
snippets) and all will work as expected.
Thanks,
David
On Wed, Dec 30, 2009 at 10:45 AM, Alex Black a...@alexblack.ca wrote:
It's not rewriting.
I didn't say it was. I just said it seemed most similar to re-writing.
Trying to mix the two will muddy the concept of rewriting and when it
happens.
Makes sense.
As far as I can tell, the two problems you are facing are:
1. There's a non-trivial amount of your code that needs to run to
render
the 404 error page. This would be corrected by the suggestion
that I
posted
regarding a LiftRule that generates the default 404 template.
2. Putting navigation on the page. I'm still noodling how to
address
this particular issue.
If there are issues other than 1 and 2, please enumerate them.
Those do sound like the issues. Just to reflect it back to you from
my perspective (in case one of us is missing something), the issue as
I see it is that I've designed a nice 404 template using lift features
(like surround, sitemap, headmerge), and I'd like to display it to the
user when no handler can be found
Whats preventing me from doing this is: the current notfound mechanism
takes a liftResponse, not a template to render, and as such forces me
to render the template itself, and although Russ proposed a way to do
that Marius indicated this could have side effects and feels like the
wrong approach.
What about Either[RewriteResponse, LiftResponse]? E.g. same as what
Marius suggested but use RewriteResponse instead of String.
On Dec 30, 1:26 pm, Marius marius.dan...@gmail.com wrote:
I thought of that but that is problematic because:
1. Having a TemplateResponse holding a path without the rendering
logic, people could use that to send a response to the client,
which
would be incorrect as having a LiftResponse holding /a/b/c
doesn;t
mean anything to a client. And this would alter the semantics of
a
LiftResponse. That's why I proposed an Either.
2. On the other hand if we have a TemplateResponse holding the
logic
of processing a template (similar to the one proposed on this
thread)
[Lift] Re: [ANN] Lift 1.1-M8
This response explains your intentions with the archetype, which is to have a warfile that you can drop into an unmodified container. I assumed it would be to get a development environment setup as quickly as possible and since jetty:run is the prescribed method of getting started, I thought it might help to recommend an alternative pom configuration. There are other methods to create a war you can drop into an unmodified container which will not break jetty:run. I've never touched JRebel because Jetty is fantastic standalone for hot redeploy provided it is configured properly. I also now see from other posts that you intend to change the h2 connection string so that Jetty can hot redeploy. You've never responded to me with that as a solution, only that the pom has no problems. That is why I felt like my issue was a non-issue and not being taken into serious consideration. So I'm sorry for getting off on the wrong foot with you David. I don't take for granted your efforts on the framework or the work you've put into making jetty easy for beginners. I was only trying to help out and for some people I have. On Dec 31, 12:10 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Dec 30, 2009 at 9:39 PM, joseph hirn joseph.h...@gmail.com wrote: Hello David. It's true that if you only have the dependency marked as provided then yes, it won't run. I am not advocating the use of using scope provided. That is only if you are programming to the h2 interfaces directly which you aren't and shouldn't be doing. I am advocating that you do not include h2 as an application dependency, but rather a dependency of the runtime environment which in this case is jetty. If you put the dependency inside of jetty and remove it from the project dependencies, it will run and survive restarts without issue. I see this post from today describing the same symptom I experience: http://groups.google.com/group/liftweb/browse_thread/thread/dd2f48174... I respectfully assert that this is an issue and that most people will not know to change up their pom file to correct the issue. Let me be clear... badgering me about in issue is not respectful. You opened a ticket and I closed it. You posted to this list and I explained why we were not going to adopt your solution. You posted twice this morning about this issue including a post about not being taken seriously. I have described my criteria for the default archetypes: they must work correctly with mvn jetty:run from the command line without any other modifications. Your proposal does not meet this criteria and I have rejected it. This is not for lack of taking you seriously. It is because I and the other Lift committers have been working with newbies and Lift for almost three years, we've been through thousands of newbie getting started questions and we've tuned Lift to make Lift easy to get started with. This means not having to set up a container as part of getting started. It is a developers choice as to how to configure their pom.xml file, but the default Lift archetype will allow the Lift app to start up correctly with mvn jetty:run or as dropped into an unmodified container. If you want something different, there's nothing about Lift that requires that the DB JAR file be specified in the pom.xml file and you are welcome to and encouraged to change it up to suit your needs. So, why is the H2/Jetty restart issue coming up today? I think the reasons are as follows: - Up until recently, Derby was the default DB for the Lift archetypes. We changed to H2 because by all measures, H2 is better. - Most developers do not rely on Jetty's code reloading features. They use JRebel or they kill and manually restart their Jetty instance. To summarize: repeatedly asking for the same thing on this list is not helpful, it's at best a waste of time. We're not removing the DB reference from the pom.xml file... you can do that if you want. We are working on the H2/Jetty restart issue. David Since the archetype is the gateway to learning the framework, it can be and is a stumbling block to those looking for a quick start into liftweb hacking. On Dec 29, 6:00 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Dec 28, 2009 at 1:13 PM, joseph hirn joseph.h...@gmail.com wrote: Thanks for the response Indrajit. Yes this is the same issue I had opened 246 for and sorry for beating a dead horse. The thing is that in most cases, you do want to container to provide the db driver. If this is the case that you want, then you can change the pom.xml file that is generated by the archetype. On the other hand, this is the default configuration that works just fine when doing mvn jetty:run. On the other hand, of you do mvn jetty:run and have H2 marked as provided, the app doesn't run. So, this is not a defect. This is the way things should be. If you
[Lift] Minor breaking changes -- LiftRules.getResourceAsStream and LiftRules.finder
Folks, I've changed LiftRules.getResourceAsStream and LiftRules.finder to return Box[Applier[InputStream]] rather than Box[InputStream]. Applier has a single method, apply[T] which takes an InputStream = T and insures the InputStream is closed. This change is unlikely to impact much code out there, but does make sure that InputStreams are closed. If any of the folks out there that name things better than I do (at least I didn't call it Apply_A_Tron), please feel free to suggest name changes, variance changes, etc. Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- 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.
Re: [Lift] cookie vs url sessionId precedence
I don't think there's a way to do this right now. Please open a ticket for it. I think this is Marius' department and he'll likely have good ideas. If it's a high priority issue for you, please put your timeframe in the ticket and post a link to the ticket in reply to this message. On Thu, Dec 31, 2009 at 12:03 PM, Jonathan Hoffman jonhoff...@gmail.comwrote: Hi, I'm using a flash upload widget to post to a Lift mapped function (/ajax_request/name/;jsessionid=x). That works fine, but there is a bug in flash on windows where it decides to send over cookies which were created in IE regardless of what browser you are now using. This causes the JSESSIONID cookie to be sent to the server which is not associated with the current browser's session. That cookie seems to take precedence over the jsessionid in the URL which means that Lift does not find the function associated with the parameter. Is there a way to tell Lift, or Jetty, that jsessionid should take precedence? or is there a way to hook in very early in the request cycle to allow filtering out cookies from the request? Also, is there an easy way to wrap a url with the correct jsessionid parameter. Currently I'm doing it manually: ;jsessionid=+S.containerSession.map(_.sessionId).openOr(). That sort of works, but I've noticed that the url is missing .WorkerName piece of the sessionId that Jetty appends to do allow load balancing to work correctly. Thanks, Jon -- 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- 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.
[Lift] Happy New Year!
Folks, For some of the Lift community, it's already 2010... for others, the new year is a scant few hours away. Before I sign off until Monday, I want to wish all of you a happy, healthy, and fun 2010. Thanks for being part of the Lift community. David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- 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.
Re: [Lift] Minor breaking changes -- LiftRules.getResourceAsStream and LiftRules.finder
StreamManager? (as in automatic resource management) Stream Don't like the above that much but nothing better comes to mind. Anyone? Also should it be apply, or doWith for consistency with AnyVars? - David Pollakfeeder.of.the.be...@gmail.com wrote: Folks, I've changed LiftRules.getResourceAsStream and LiftRules.finder to return Box[Applier[InputStream]] rather than Box[InputStream]. Applier has a single method, apply[T] which takes an InputStream = T and insures the InputStream is closed. This change is unlikely to impact much code out there, but does make sure that InputStreams are closed. If any of the folks out there that name things better than I do (at least I didn't call it Apply_A_Tron), please feel free to suggest name changes, variance changes, etc. Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- 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.
[Lift] warning: value rewrite in object LiftRules is deprecated
Two questions: 1. Whats the replacement for LiftRules.rewrite? 2. Is there a way I can write a custom Loc so that SiteMap is aware of the re-writing? I'm following the AccountLoc extends Loc[AccountInfo] example in the book, but my rewriting is not having any effect yet, I am trying to figure out what I am missing. - Alex -- 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.
Re: [Lift] warning: value rewrite in object LiftRules is deprecated
Instead of LiftRules.rewrite, use LiftRules.statelessRewrite if you want the old behavior (e.g. rewriting while S is not available) If you have rewrites that require S to be available, then you can use the new LiftRules.statefulRewrite I'm not sure about the SiteMap question. -Ross On Dec 31, 2009, at 4:55 PM, Alex Black wrote: Two questions: 1. Whats the replacement for LiftRules.rewrite? 2. Is there a way I can write a custom Loc so that SiteMap is aware of the re-writing? I'm following the AccountLoc extends Loc[AccountInfo] example in the book, but my rewriting is not having any effect yet, I am trying to figure out what I am missing. - Alex -- 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.
[Lift] Re: Nice 404s sans Redirect
That sounds great.
Just curious though, is there any chance runTemplate should just do
the head merge?
On Dec 31, 3:12 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Wed, Dec 30, 2009 at 7:43 PM, Alex Black a...@alexblack.ca wrote:
Ok, I tried this, it gets closer.
I noticed one issue: the head merge didn't get done, so I have two
head tags in the result. I'm attempting to set the title in the
404.html template, maybe there is a way I can set the title without
using head merge?
I'm opening up the merge method, so once the code is in master, you'll be
able to do:
def generate404(): LiftResponse = {
import scala.xml.Node
val resp: Box[Node] = S.setVars(expandAll - true) {
for {
session - S.session
req - S.request
rendered - S.runTemplate(404 :: Nil)
} yield session.performHeadMerge(rendered, req)
}
XhtmlResponse(resp openOr htmlbodyGot a 404/body/html,
Empty, List(Content-Type - text/html; charset=utf-8),
Nil, 404, S.ieMode)
}
This will do the head merge and give you the ability to do anything Lift
does.
- Alex
On Dec 30, 2:54 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
In Boot.scala (the boot method):
LiftRules.passNotFoundToChain = false
LiftRules.uriNotFound.prepend {
case _ = generate404()
}
In the Boot class:
def generate404(): LiftResponse = {
import scala.xml.Node
val resp: Box[Node] = S.setVars(expandAll - true) {
for {
rendered - S.runTemplate(404 :: Nil)
} yield rendered(0)
}
XhtmlResponse(resp openOr htmlbodyGot a 404/body/html,
Empty, List(Content-Type - text/html;
charset=utf-8),
Nil, 404, S.ieMode)
}
And a 404.html file (which can be localized):
lift:surround with=default at=content
Couldn't find your page... sorry
/lift:surround
The uriNotFound code is executed within the S scope, so you've got all
the
goodness of knowing who the current user is, etc.
The reason that the menu was not being rendered in your example is that
menu
rendering is based on the location property in the Req(uest). If there
is
no location (as defined in the SiteMap), then no menu can be rendered.
There's an option for displaying the entire sitemap by setting the
expandAll=true attribute when invoking the Menu.builder snippet. But
you
don't really want to show the entire menu on all pages, so the
S.setVars(expandAll - true) {...} method (which is a good candidate
for
renaming for all you renamers out there) allows us to set the expandAll
attribute for the duration of the code block.
Then we use S.runTemplate() to locate and run the 404.html template.
Finally, we create the XhtmlResponse with the 404 error code.
So, you can put whatever you want in the 404.html template (including
snippets) and all will work as expected.
Thanks,
David
On Wed, Dec 30, 2009 at 10:45 AM, Alex Black a...@alexblack.ca wrote:
It's not rewriting.
I didn't say it was. I just said it seemed most similar to re-writing.
Trying to mix the two will muddy the concept of rewriting and when it
happens.
Makes sense.
As far as I can tell, the two problems you are facing are:
1. There's a non-trivial amount of your code that needs to run to
render
the 404 error page. This would be corrected by the suggestion
that I
posted
regarding a LiftRule that generates the default 404 template.
2. Putting navigation on the page. I'm still noodling how to
address
this particular issue.
If there are issues other than 1 and 2, please enumerate them.
Those do sound like the issues. Just to reflect it back to you from
my perspective (in case one of us is missing something), the issue as
I see it is that I've designed a nice 404 template using lift features
(like surround, sitemap, headmerge), and I'd like to display it to the
user when no handler can be found
Whats preventing me from doing this is: the current notfound mechanism
takes a liftResponse, not a template to render, and as such forces me
to render the template itself, and although Russ proposed a way to do
that Marius indicated this could have side effects and feels like the
wrong approach.
What about Either[RewriteResponse, LiftResponse]? E.g. same as what
Marius suggested but use RewriteResponse instead of String.
On Dec 30, 1:26 pm, Marius marius.dan...@gmail.com wrote:
I thought of that but that is problematic because:
1. Having a TemplateResponse holding a path without the rendering
logic, people could use that to send a response to the client,
which
would be incorrect as having a LiftResponse holding /a/b/c
doesn;t
mean anything to a client. And this
[Lift] Re: Sitemap: Using instead of index and still having the current menu selected?
That sounds great, much appreciated. On Dec 31, 2:52 pm, David Pollak feeder.of.the.be...@gmail.com wrote: I was in SiteMap for another project today. I'll add a flag on the SiteMap object that facilitates / rather than /index. On Wed, Dec 30, 2009 at 7:47 PM, Alex Black a...@alexblack.ca wrote: Would it be reasonable for me to open a ticket to allow people to change this default behaviour? Its important to me that when people are at our site's home page, its just http://oursite.com;, not http://oursite.com/index;. Then for people who are using a container where this is a problem, it will work fine, but others can avoid the index in the url. - Alex On Dec 30, 12:49 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Dec 30, 2009 at 9:43 AM, Alex Black a...@alexblack.ca wrote: In a 1.1-M8 based project, http://localhost:8080/andhttp://localhost:8080/indexbothcausethe Home menu item to be non-clickable. The definition of the Home menu item is Menu(Loc(Home, List(index), Home)) Understood. However, in this scenario, when the user clicks on home they get taken tohttp://localhost:8080/index, I think it would be even better if they could be taken tohttp://localhost:8080/. Its mostly aesthetic, but its cleaner/shorter, and it saves having two URLs for the same thing (e.g.http://localhost:8080/and http://localhost:8080/index). Is there any way to do that while maintaining the nice Sitemap feature that makes Home non clickable? As I said already, we had thehttp://localhost:8080/asthe place where the top level takes you. That broke some containers (I don't remember the specifics) so the top level is /index. There's no way to change it and it is this way for the reason that I've now had to state twice in two days. - Alex Also, why do you using Pair(List(...), false)? Pair is deprecated/frowned on... it's much more idomatic to use (List(...), false), but that's not needed as there's an implicit conversion you can simply declare the List(). Thanks for the tip. to Menu(Loc(index, Pair( :: Nil, false), Home)) :: So that my Home link goes to mysite.com/ instead of mysite.com/ index. But, I notice, when you're at mysite.com/ the sitemap doesn't show Home as selected, is there a way to fix that? Perhaps I've got something wrong here. Thanks, - Alex -- 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.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com liftweb%252bunsubscr...@googlegroups.comliftweb%25252bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com liftweb%252bunsubscr...@googlegroups.comliftweb%25252bunsubscr...@googlegroups.com liftweb%252bunsubscr...@googlegroups.comliftweb%25252bunsubscr...@googlegroups.com liftweb%25252bunsubscr...@googlegroups.comliftweb%2525252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- 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.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com liftweb%252bunsubscr...@googlegroups.comliftweb%25252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- 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.comliftweb%2bunsubscr...@googlegroups.com
[Lift] Re: warning: value rewrite in object LiftRules is deprecated
Thanks! On Dec 31, 5:03 pm, Ross Mellgren dri...@gmail.com wrote: Instead of LiftRules.rewrite, use LiftRules.statelessRewrite if you want the old behavior (e.g. rewriting while S is not available) If you have rewrites that require S to be available, then you can use the new LiftRules.statefulRewrite I'm not sure about the SiteMap question. -Ross On Dec 31, 2009, at 4:55 PM, Alex Black wrote: Two questions: 1. Whats the replacement for LiftRules.rewrite? 2. Is there a way I can write a custom Loc so that SiteMap is aware of the re-writing? I'm following the AccountLoc extends Loc[AccountInfo] example in the book, but my rewriting is not having any effect yet, I am trying to figure out what I am missing. - Alex -- 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.
Re: [Lift] warning: value rewrite in object LiftRules is deprecated
Can the deprecration message be made to say so? - Ross Mellgrendri...@gmail.com wrote: Instead of LiftRules.rewrite, use LiftRules.statelessRewrite if you want the old behavior (e.g. rewriting while S is not available) If you have rewrites that require S to be available, then you can use the new LiftRules.statefulRewrite I'm not sure about the SiteMap question. -Ross On Dec 31, 2009, at 4:55 PM, Alex Black wrote: Two questions: 1. Whats the replacement for LiftRules.rewrite? 2. Is there a way I can write a custom Loc so that SiteMap is aware of the re-writing? I'm following the AccountLoc extends Loc[AccountInfo] example in the book, but my rewriting is not having any effect yet, I am trying to figure out what I am missing. - Alex -- 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. -- 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.
[Lift] Re: Problem in Lift 1.1-SNAPSHOT ?
I'm not quite understanding... I just got the zip files from the download page of the GitHub (http://github.com/dpp/liftweb/downloads) for both 1.1-M7 and Lift-1.1-M8-release. Both of them fail the build with the same error: C:\Users\mark\Library\Lift-1.1-M7\lift-modules\lift-jta\src\main\scala \net\liftweb\transaction\TransactionContext.scala:206: error: class TransactionContext needs to be abstract, since method getUnitName in trait ScalaEMFactory of type = String is not defined class TransactionContext(private implicit val transactionService: TransactionService) ^ one error found Are those snapshots/releases not complete? I ran mvn install (no clean, since I just downloaded the zip...) According to the pom, the Scala version they want is 2.7.7. I imagine maven gets the compiler from the proper scala jar file instead of using the system compiler. Even if that's not true, my SCALA_HOME points to 2.7.7 and 'which scalac' points to the 2.7.7 version. (FWIW, this also happens for 'mvn clean install' not surprisingly) I guess since it's in the jta module I don't really care since I'm not using that... Cheers, Mark -- 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.
Re: [Lift] Re: Lift is awesome (with reservations)
Okay, Erkki, I suppose you should just post all your thoughts to the list. We're eagerly awaiting them! On Wed, Dec 30, 2009 at 6:06 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: Okay, I hear what your saying. Personally I think it's partially how you sell it, but if you think it will supress discussion then I guess we can just discuss it directly on the list. What do you say to having, in general, one thread per class being discussed (that is, assuming people stick to the idea to focus on one class at a time), and prefixing the subject with [naming] or something like that? - Jim Barrowsjim.barr...@gmail.com wrote: Note: I just realized this was gonig to the list, and individual emails as well. edited the to and cc fields. On Wed, Dec 30, 2009 at 2:22 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: I'm confused by your reply. Firstly, I think I was clear that I'm not going to do anything that you or David disapprove of. So if my idea is not a good one just scratch it! In any case I'm confused by what you said. What is hidden about a Google Docs document? Whoever wants to participate in the discussion can write in the document. The first problem is that anyone who might wish to comment hase to know about it. How often people either not check, not check thoroughly enough the existing mailing list as it is?So now you want them to read the mailing list or the wiki to find out about a discussion happening someplace else? That's going to complicate matters a whole lot. The second problem is that you won't be able to get away from the implication that things are being done behind the communities back. Pretty much no matter what you do. Again the problem is human beings. Everybody is not going to search, and some people are going to feel like that without a personal invitation to join the elite working way over here, they have no opportunity to participate. The spreadsheet I created is just a data tracker. I fully expect, and encourage the discussions to happen on the lists. The limited number of people who can write to it is to prevent discussions happening away from the list, not to limit the discussion itself. That's why it has columns to put links to discussion on it. And if three people, or ten, discuss it there and then run it by everyone on the list, those people will certainly not ignore what others on the list have to say. Was I unclear in the previous message? Or is my ignorance of Google Docs at play? Or did I misunderstand something? There's a huge difference between people working together, coming to the list and going what's the best way to solve 'X', or we think 'Y' would better the 'X' because of blah blah, and people working together and coming to the list and going Change this!.There's an even bigger difference when the latter are some sort of Refactor and Reorganize Lift Committee. Thanks. - Jim Barrowsjim.barr...@gmail.com wrote: On Wed, Dec 30, 2009 at 11:29 AM, Naftoli Gugenheim naftoli...@gmail.com wrote: 100%. But that need could be reconciled with my idea in either of two ways: 1. There is discussion taking place, just in the Google Docs file as opposed to the maling list. Anyone who wants can participate. The point is that I suspect much of the reason everyone wants better naming but no one is doing anything, is because there's a lot of overhead besides the actual act of discussion. I think we need an approach that lets people 'just discuss' the names in context, without any extra work like copy pasting into spreadsheets etc. So, you're trying to drive disucssion to some place hidden from the rest of the list (and by list I mean, users and creators of Lift). 2. If that's not satisfactory, then we can summarize the discussion on the list or just run the conclusion by everyone on the list. This way the discussion itself will remain lighweight and overhead-less, but it will still have to go through public scrutiny on the list before any ticket is filed. To present the users and creators of Lift with, essentially, a fait accompli? Leave me out of that one. Of course if you still object we're all ears! Thanks. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Tue, Dec 29, 2009 at 7:16 PM, Naftoli Gugenheim naftoli...@gmail.com wrote: Does anyone object to this approach? Any source file that's being reviewed (hopefully one or very few at a time) should be uploaded to Google Docs as a text document. Discussion can consist of the built in google chat functionality but mainly by inserting a ((( ... ))) section in scaladoc comments and writing your name and thoughts there. The advantage to this poor man's code
