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
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:
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
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
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.
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
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
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.
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
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
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
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:
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.
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
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
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
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
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
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
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
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
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
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
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:
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
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
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))
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
44 matches
Mail list logo
