[Lift] How to install non-standard Lift from GitHub
I have pulled and built a certain Lift branch from the GitHub on my Mac, and I would like to temporarily switch to using that branch. Do I have to make an installer app (how?) and run that, or could I just set up some pointer(s) (like an environment variable) to the directory where all the new jars are? (I may want to switch back to standard Lift 1.0 soon afterwards.) /Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: How to install non-standard Lift from GitHub
Jon, Assuming you are using Maven (you probably are if you used the installer), you can move to the lift-core module and do an 'mvn install' to have everything built and deployed in the local Maven repository. (cd lift-core ; mvn install) Subsequently, you can modify your projects pom.xml to have lift-core dependency set to 1.1-SNAPSHOT (you must be having 1.0 there) to use the version that you just built. You can revert the lift-core dependency to 1.0 to switch back to standard Lift 1.0. /irc On Jul 25, 7:46 pm, Jon Kleiser jon.klei...@usit.uio.no wrote: I have pulled and built a certain Lift branch from the GitHub on my Mac, and I would like to temporarily switch to using that branch. Do I have to make an installer app (how?) and run that, or could I just set up some pointer(s) (like an environment variable) to the directory where all the new jars are? (I may want to switch back to standard Lift 1.0 soon afterwards.) /Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Lift (AsyncWeb || ...)
Hi, Did anyone played with AsyncWeb? .. Looks pretty promising but I think having Lift working properly with it we need some adaptions. For instance: 1. Lift uses HttpServletXXX references provided by JEE containers. One solution that avoids vast code change is Lift is to bridge AsyncWeb API through our own implementation of HttpServlet, HttpServletXXX etc. 2. Session management .. We'd also need a bridge for HttpSession .. but that should be pretty straight forward. (Fortunately we have LiftSession only bridged to HTTP session today.) 3. Comet support. Async Web fundamental concept seems to map pretty well to Comet model. Probably they don't have the suspend/resume mechanism as Jetty but there are some other means to do it right. Need to look more into it ... The point is that perhaps we should expand a bit and not depend so much on JEE web container anymore as there are other viable alternatives. We just need to build a flexible and transparent wiring mechanism. I'll probably start looking more into this path but first I'd like to see your thoughts ... Br's, Marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: Lift (AsyncWeb || ...)
Hey Marius, I read your email with interest - myself and viktor were only today discussing all the various technologies such as this which are now flooding the wider JEE eco-system and how lift can interoperate with them (or if indeed we need to / should) I think perhaps there is something wider to consider here: possibly abstract things away so pluging lift into something other than HttpServlet is fairly straight forward. You talk below about AsyncWeb, but it seems the same might be true for the Grizzly NIO family of projects? Im not sure, nor am I familiar with them in great detail but your right, there are a lot of new options now that didn't previously exist so we should be considering them. Today I read a preso that was suggesting servlet 3.0 wont deliver feature-full cross-container comet support as everyone had hoped; if that's the case, then sure, supporting other architectures would probably be a pretty good idea :-) Cheers, Tim On 25/07/2009 19:06, Marius marius.dan...@gmail.com wrote: Hi, Did anyone played with AsyncWeb? .. Looks pretty promising but I think having Lift working properly with it we need some adaptions. For instance: 1. Lift uses HttpServletXXX references provided by JEE containers. One solution that avoids vast code change is Lift is to bridge AsyncWeb API through our own implementation of HttpServlet, HttpServletXXX etc. 2. Session management .. We'd also need a bridge for HttpSession .. but that should be pretty straight forward. (Fortunately we have LiftSession only bridged to HTTP session today.) 3. Comet support. Async Web fundamental concept seems to map pretty well to Comet model. Probably they don't have the suspend/resume mechanism as Jetty but there are some other means to do it right. Need to look more into it ... The point is that perhaps we should expand a bit and not depend so much on JEE web container anymore as there are other viable alternatives. We just need to build a flexible and transparent wiring mechanism. I'll probably start looking more into this path but first I'd like to see your thoughts ... Br's, Marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Image problems...
I'm completely stumped. I'll give the background for the sake of completeness but I'm not sure if it will help or not. It's more of a Jetty problem but perhaps someone here can help. Standard Jetty set-up running one Lift instance. Mac OS X. I have a snippet which transforms the XML input, renders an image, saves it to disc under the webroot/images/ directory with a filename taken from the MD5 of the contents, such as c5669d3eedcf7d305dcf9f88a61b3ee0.png . The snippet then returns an img / with a reference to the generated image for inclusion in the output. Most of the time most of the images work. But most of the time some of them don't, and some of the images are not rendered by the browser. Attempting to view a problem image in the browser (Camino and Firefox) doesn't work: the image is not displayed, suggesting that something is vaguely wrong. Viewing it in another browser (Safari and with QuickTime), the image works fine. When viewing the file directly with Camino (i.e. file://...), the image shows fine (the file itself is not corrupted). I can only assume that something goes wrong in the transport of the image. The URIs that do fail, fail consistently, it's not intermittent. Restarting Jetty makes no difference, so I don't think it's that the file was created after the server started. Also, the render is a blocking call, so there's no chance that the file is still open / hasn't been saved before the HTML is sent and the browser requests the images. The only thing I can imagine is that the MIME type is mangled, so I put the appropriate mapping in web.xml: mime-mapping extensionpng/extension mime-typeimage/png/mime-type /mime-mapping But still no cigar. The MIME type looks to be OK and I've verified that the number of bytes is correct. HTTP/1.1 200 OK Expires: Thu, 01 Jan 1970 00:00:00 GMT Set-Cookie: JSESSIONID=1dbeh8eq4mtu0;Path=/ Content-Type: image/png Content-Length: 25488 Last-Modified: Sat, 25 Jul 2009 15:38:19 GMT Server: Jetty(6.1.16) For completeness, the headers from an image that does load fine: HTTP/1.1 200 OK Expires: Thu, 01 Jan 1970 00:00:00 GMT Set-Cookie: JSESSIONID=15dt649lzovc4;Path=/ Content-Type: image/png Content-Length: 18657 Last-Modified: Sat, 25 Jul 2009 15:41:35 GMT Server: Jetty(6.1.16) Very very puzzled about this. Any clues? Cheers Joe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: Lift (AsyncWeb || ...)
On Jul 25, 9:25 pm, Timothy Perrett timo...@getintheloop.eu wrote: Hey Marius, I read your email with interest - myself and viktor were only today discussing all the various technologies such as this which are now flooding the wider JEE eco-system and how lift can interoperate with them (or if indeed we need to / should) I think perhaps there is something wider to consider here: possibly abstract things away so pluging lift into something other than HttpServlet is fairly straight forward. You talk below about AsyncWeb, but it seems the same might be true for the Grizzly NIO family of projects? Most definitely ... my goal would be to be HTTP platform agnostic. If the platform can deliver proper Comet support. AsyncWeb here is just an example that can serve as a reference implementation. Im not sure, nor am I familiar with them in great detail but your right, there are a lot of new options now that didn't previously exist so we should be considering them. Today I read a preso that was suggesting servlet 3.0 wont deliver feature-full cross-container comet support as everyone had hoped; if that's the case, then sure, supporting other architectures would probably be a pretty good idea :-) I think that supporting other non JEE architectures is important regardless if servlet 3.0 can deliver or not their claims. Widening Lift underlying HTTP platform would be a huge gain IMHO. Cheers, Tim On 25/07/2009 19:06, Marius marius.dan...@gmail.com wrote: Hi, Did anyone played with AsyncWeb? .. Looks pretty promising but I think having Lift working properly with it we need some adaptions. For instance: 1. Lift uses HttpServletXXX references provided by JEE containers. One solution that avoids vast code change is Lift is to bridge AsyncWeb API through our own implementation of HttpServlet, HttpServletXXX etc. 2. Session management .. We'd also need a bridge for HttpSession .. but that should be pretty straight forward. (Fortunately we have LiftSession only bridged to HTTP session today.) 3. Comet support. Async Web fundamental concept seems to map pretty well to Comet model. Probably they don't have the suspend/resume mechanism as Jetty but there are some other means to do it right. Need to look more into it ... The point is that perhaps we should expand a bit and not depend so much on JEE web container anymore as there are other viable alternatives. We just need to build a flexible and transparent wiring mechanism. I'll probably start looking more into this path but first I'd like to see your thoughts ... Br's, Marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Rational Behind One Callback per Form Field
Hi all,
I've been working with Lift for about a little while now; there are
still plenty of aspects of Lift I haven't touched yet. One thing I am
curious about at this point though is the rationale behind having one
callback per field when generating forms. Each SHtml form element
needs to be handed its own call back function. This strikes me as a
kind of cumbersome, for instance the form examples on the Wiki and in
the Exploring Lift book all follow this pattern:
someSnippet(xml: NodeSeq) = {
var fieldOne =
var fieldTwo =
def sumbitHandler() = { ... }
bind(prefix, xml,
fieldOne - SHtml.text(fieldOne, fieldOne = _),
fieldTwo - SHtml.text(fieldTwo, fieldTwo = _),
formSubmit - SHtml.submit(Submit, submitHandler))
}
I've seen several examples of this exact pattern at this point and it
makes the whole fieldOne = _ callback seem like needless boiler-plate.
Why not allow for just one callback function that works over some
object encapsulating an entire form? Am I missing something?
As a corollary to this question, are there other mechanisms available
in Lift for form generation/processing?
Cheers
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@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] url rewrite subdomain?
Hi all, most examples I have seen about Lift URL rewriting are about the path of the URL, the part that comes after the hostname (and port). But is it also possible to do URL rewriting on subdomains? For instance, can I rewrite a URL where the account name is used as a subdomain, something like: http://myaccount.example.com so that it maps to something similar to http://www.example.com?account=myaccount And is URL rewriting for subdomains always possible, or are there some prerequisities from a hosting company or something? Thanks! JanWillem Tulp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] log4j problems with Jetty
Hi, I'm trying to use the jetty plugin for gradle (a Groovy build tool ala buildr) and I'm getting the following error when loading the Lift app: 3:52:11.276 [main] ERROR org.mortbay.log - failed LiftFilter java.lang.IllegalAccessError: tried to access method org.apache.log4j.Logger.init(Ljava/lang/String;)V from class org.apache.log4j.spi.RootLogger at org.apache.log4j.spi.RootLogger.init(RootLogger.java:43) at org.apache.log4j.LogManager.clinit(LogManager.java:78) at net.liftweb.util.LogBoot$.log4jIsConfigured$1(Log.scala:113) at net.liftweb.util.LogBoot$._log4JSetup(Log.scala:129) I assume there are some logging conflicts somewhere, but can't seem to figure out where. Any clues to what the issue is? This is the classpath used: 23:52:08.786 [main] DEBUG org.mortbay.log - webapp=file:/Users/jeppe//build/jetty/webapp/ 23:52:08.787 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/classes/ 23:52:08.788 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/activation-1.1.jar 23:52:08.788 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/avalon-framework-4.1.3.jar 23:52:08.789 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/commons-codec-1.3.jar 23:52:08.789 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/commons-collections-3.2.1.jar 23:52:08.789 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/commons-fileupload-1.2.1.jar 23:52:08.789 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/commons-httpclient-3.1.jar 23:52:08.790 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/commons-logging-1.1.jar 23:52:08.790 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/dom4j-1.6.1.jar 23:52:08.790 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/lift-actor-1.1-SNAPSHOT.jar 23:52:08.790 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/lift-mapper-1.1-SNAPSHOT.jar 23:52:08.791 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/lift-util-1.1-SNAPSHOT.jar 23:52:08.792 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/lift-webkit-1.1-SNAPSHOT.jar 23:52:08.793 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/lift-widgets-1.1-SNAPSHOT.jar 23:52:08.793 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/log4j-1.2.14.jar 23:52:08.793 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/logkit-1.0.1.jar 23:52:08.794 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/mail-1.4.jar 23:52:08.794 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/ooxml-schemas-1.0.jar 23:52:08.808 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/poi-3.5-beta6.jar 23:52:08.808 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/poi-ooxml-3.5-beta6.jar 23:52:08.824 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/postgresql-8.3-603.jdbc4.jar 23:52:08.824 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/scala-compiler-2.7.5.jar 23:52:08.824 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/scala-library-2.7.5.jar 23:52:08.824 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/stax-api-1.0.1.jar 23:52:08.824 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/xml-apis-1.0.b2.jar 23:52:08.825 [main] DEBUG org.mortbay.log - Path resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/xmlbeans-2.3.0.jar /Jeppe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: ToDo example
btw, when I said stupid questions, I was talking about the questions I was about to ask, not yours. :) I wrote it real fast and realized it could be taken the wrong way. :) On Sat, Jul 25, 2009 at 10:09 PM, Kevgriffin@gmail.com wrote: I was working through the ToDo example on the web http://liftweb.net/docs/getting_started/mod_master.html#x1-12.4 but when I add the ToDo to the line Schemifier.schemify(true, Log.infoF _, User, ToDo) I get file not found exceptions at compile time, have I missed a step? the import is correct and my todo clas is in the correct location. Hopefully it's late and I have missed some thing... thanks, Kevin -- Omnem crede diem tibi diluxisse supremum. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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: Rational Behind One Callback per Form Field
I hope to commit in the next few days code that makes a couple of similar asks
easier BH.
But, to put the ball in your court, how exactly do you want your code to look?
If you write a complete sample usage I'll see what I can do to implement such
functionality.
Also, Kris, could you elaborate on how the first way would help track values
and how it would make the option case easier, and explain the second way better?
Thanks.
-
Kris Nuttycombekris.nuttyco...@gmail.com wrote:
On Sat, Jul 25, 2009 at 3:18 PM, Devon Tuckerdevonrtuc...@gmail.com wrote:
Hi all,
I've been working with Lift for about a little while now; there are
still plenty of aspects of Lift I haven't touched yet. One thing I am
curious about at this point though is the rationale behind having one
callback per field when generating forms. Each SHtml form element
needs to be handed its own call back function. This strikes me as a
kind of cumbersome, for instance the form examples on the Wiki and in
the Exploring Lift book all follow this pattern:
someSnippet(xml: NodeSeq) = {
var fieldOne =
var fieldTwo =
def sumbitHandler() = { ... }
bind(prefix, xml,
fieldOne - SHtml.text(fieldOne, fieldOne = _),
fieldTwo - SHtml.text(fieldTwo, fieldTwo = _),
formSubmit - SHtml.submit(Submit, submitHandler))
}
I've seen several examples of this exact pattern at this point and it
makes the whole fieldOne = _ callback seem like needless boiler-plate.
Why not allow for just one callback function that works over some
object encapsulating an entire form? Am I missing something?
This is a pretty interesting question; I've sometimes wondered whether
the use of bare closures for this purpose isn't a bit too close to the
metal. It would be possible to do something like what you describe,
but the binding of each form element would still have to have some
reference to the variable being set. Now this could conceivably be
achieved in a few different ways:
You could have each bound variable, instead of being a regular Scala
variable, be an object extending some trait that the SHtml field
builders know about. This would mean that you'd just pass references
to those objects to the field builders, and they'd be automatically
mutated with the form field value on submit. The amount of boilerplate
-- maybe something like object fieldOne extends StringField -- would
be similar to what you get from the current situation. The one thing I
like about this is that the state of such a field could be tracked a
bit better; in the past I've found myself with a lot of code like the
following:
var fieldOne: Option[MyObject] = None
val options: Seq[(MyObject, String)] = ...
bind(prefix, xml,
myselect - SHtml.selectObj(options, Empty, a = fieldOne = Some(a))
just to avoid mucking about with nulls, and this definitely gets laden
with boilerplate when you have a bunch of fields, particularly in the
handler function.
You could have the SHtml field builders return some sort of object
apart from an XML node, store that in a local val, and then have your
form-level callback refer to that value. This seems like an attractive
possibility to me because it could eliminate the need for mutable
variables entirely; the resulting objects could dynamically obtain
their submitted values from the Req when referenced by the callback
function.
Neither of these approaches exist yet, but you could build either one
of them atop the current framework, which I think is sort of one of
the main points of Lift at this stage in its development - it gives
you the most powerful tools it can, and one can build higher-level
abstractions atop what it provides.
Kris
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@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
-~--~~~~--~~--~--~---
