Re: [Lift] Re: How to get the servlet context
On Wed, Dec 2, 2009 at 5:27 AM, jhonig al...@xs4all.nl wrote: David, I'm all for putting stuff in a well-know location in the filesystem... and defining that well known location in the props file. OK, then this is what I want. But you refer to THE props file. Do you mean a Jetty props file, a general Lift props file, a user defined props file? Lift has a properties mechanism (see net.liftweb.util.Props). You can define properties based on user name, machine name, and runmode. This allows you to have different temporary directories depending on the developer/machine/run mode. I tried to use a symbolic link from the WAR to an absolute fs location, but that was not allowed... Messing around with trying to figure out where the app server has exploded your WAR file (if it even has which is not AFAIK guaranteed) and putting files in there is a failure waiting to happen. OK, I see. Job -- 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: How to get the servlet context
Storing files inside the exploded WAR file is a tremendously bad idea. I don't think we should be helping a user do something that is going to continue to cause him pain. If he needs to upload images, etc. and then subsequently present them to the user, it's two tables in the RDBMS and a single stateless dispatch. All in all 40 lines of code and no pain. On Mon, Nov 30, 2009 at 2:08 PM, Marius marius.dan...@gmail.com wrote: Ahh so you want direct links to those files. Still you can do something else. Point your URI's from your page to a specific uri such as /myapp/serve/myimage.jpg. You intercept requests to myapp :: serve :: _ using a DispatchPF. The dispatch PF knows about your folder location (presumably from a config file) and reads myimage.jpg from that path on the file system. Hence you can read the File and send it to the client. I think you can use Lift's StreamResponse or you can build your own LiftResponse that returns a file using proper Content-Type. Another approach would be to use a reverse proxy server in front of your Lift application (this is a common production deployment model that server static content from frontend server not app servers), your Lift application could simply write files in the document-root folder hence would be seen by the proxy server and served to the client. I used in the past both options with no problem at all for use cases not so different than yours. Brs, Marius On Nov 30, 11:36 pm, jhonig al...@xs4all.nl wrote: Marius, I tried to create a link from the webapp dir to another location with rw-access, but that was not allowed... My conclusion was that you can't have symbolic links to locations outside the war. My problem is that there are three different locations that could all be interpreted as a root for looking up resources. I've found nothing suggesting one over the other, and none of them works. I assume there are more variables involved that I don't even know of. Job On Nov 30, 10:27 pm, Marius marius.dan...@gmail.com wrote: Ok I may be missing something essential from all this thread but why not use a folder from the user's home directory? If your app runs say under jetty OS user should heve read/write rights to write on the home user file-system. Even if not (although I haven't encountered the case) those rights can be granted by an admin. So why do you need special container allocated locations to write files? Br's, Marius On Nov 30, 11:18 pm, jhonig al...@xs4all.nl wrote: Hi Tim, Jeppe, and others who have replied... I have spent a few more hours, but there are just too many variables and I haven't been able to figure them out. I logged the various locations (running under a standalone jetty, not mvn jetty:run, and got this: INFO - TEMP = /tmp/Jetty_0_0_0_0_8080_tent. 0.1.SNAPSHOT.warvtra6b INFO - REAL = /tmp/Jetty_0_0_0_0_8080_tent. 0.1.SNAPSHOT.warvtra6b/webapp INFO - URL = file:/tmp/Jetty_0_0_0_0_8080_tent. 0.1.SNAPSHOT.warvtra6b/webapp/WEB-INF/classes/ I tried to access images, both from the HTML served to my browser and from Scala snippets. I used the following paths: Images/testimage.jpg work/Images/testimage.jpg classes/work/Images/testimage.jpg WEB-INF/classes/work/Images/testimage.jpg. The latter path is what I see in my .war file... I have no special filters. I tried to add entries to my site map, but none of them worked. About to give up. Hope somebody will help me. Job H. On Nov 28, 3:14 pm, jhonig al...@xs4all.nl wrote: Dear Tim and Heiko, I tested a few things under mvn jetty:run...: getRealPath gives me ./src/main/webapp the temp attribute is set to ./target/work and the location is ./target/classes While the war contains classes/work which is again different... I didn't manage to get jetty to serve contents from any other directory than the first one. Didn't try to run it on the standalone jetty, since I still don't know how to tell jetty to serve contents that is not under the webapp directory. Probably have to do something with the site map which I don't fully understand. Guess my main problem is that I don't have any experience in this field (jetty/lift) and thought it wouldn't be to difficult to port my website to lift and enhance it a little on the fly. To be continued... Job Honig On Nov 28, 12:52 am, Timothy Perrett timo...@getintheloop.eu wrote: Here's a nugget of information for you that will help (as I do something similar to what you want in one of my applications): val protectionDomain: ProtectionDomain = classOf[bootstrap.liftweb.Boot].getProtectionDomain() val location: URL =
Re: [Lift] Re: How to get the servlet context
Sometimes its an unavoidable fact that we need to store stuff on the file-system. Im not promoting inside the exploded war, but knowing your location and going from there can be a useful aid; its certainly something that i've done before with success. Cheers, Tim On 30 Nov 2009, at 22:30, David Pollak wrote: Storing files inside the exploded WAR file is a tremendously bad idea. I don't think we should be helping a user do something that is going to continue to cause him pain. If he needs to upload images, etc. and then subsequently present them to the user, it's two tables in the RDBMS and a single stateless dispatch. All in all 40 lines of code and no pain. On Mon, Nov 30, 2009 at 2:08 PM, Marius marius.dan...@gmail.com wrote: Ahh so you want direct links to those files. Still you can do something else. Point your URI's from your page to a specific uri such as /myapp/serve/myimage.jpg. You intercept requests to myapp :: serve :: _ using a DispatchPF. The dispatch PF knows about your folder location (presumably from a config file) and reads myimage.jpg from that path on the file system. Hence you can read the File and send it to the client. I think you can use Lift's StreamResponse or you can build your own LiftResponse that returns a file using proper Content-Type. Another approach would be to use a reverse proxy server in front of your Lift application (this is a common production deployment model that server static content from frontend server not app servers), your Lift application could simply write files in the document-root folder hence would be seen by the proxy server and served to the client. I used in the past both options with no problem at all for use cases not so different than yours. Brs, Marius On Nov 30, 11:36 pm, jhonig al...@xs4all.nl wrote: Marius, I tried to create a link from the webapp dir to another location with rw-access, but that was not allowed... My conclusion was that you can't have symbolic links to locations outside the war. My problem is that there are three different locations that could all be interpreted as a root for looking up resources. I've found nothing suggesting one over the other, and none of them works. I assume there are more variables involved that I don't even know of. Job On Nov 30, 10:27 pm, Marius marius.dan...@gmail.com wrote: Ok I may be missing something essential from all this thread but why not use a folder from the user's home directory? If your app runs say under jetty OS user should heve read/write rights to write on the home user file-system. Even if not (although I haven't encountered the case) those rights can be granted by an admin. So why do you need special container allocated locations to write files? Br's, Marius On Nov 30, 11:18 pm, jhonig al...@xs4all.nl wrote: Hi Tim, Jeppe, and others who have replied... I have spent a few more hours, but there are just too many variables and I haven't been able to figure them out. I logged the various locations (running under a standalone jetty, not mvn jetty:run, and got this: INFO - TEMP = /tmp/Jetty_0_0_0_0_8080_tent. 0.1.SNAPSHOT.warvtra6b INFO - REAL = /tmp/Jetty_0_0_0_0_8080_tent. 0.1.SNAPSHOT.warvtra6b/webapp INFO - URL = file:/tmp/Jetty_0_0_0_0_8080_tent. 0.1.SNAPSHOT.warvtra6b/webapp/WEB-INF/classes/ I tried to access images, both from the HTML served to my browser and from Scala snippets. I used the following paths: Images/testimage.jpg work/Images/testimage.jpg classes/work/Images/testimage.jpg WEB-INF/classes/work/Images/testimage.jpg. The latter path is what I see in my .war file... I have no special filters. I tried to add entries to my site map, but none of them worked. About to give up. Hope somebody will help me. Job H. On Nov 28, 3:14 pm, jhonig al...@xs4all.nl wrote: Dear Tim and Heiko, I tested a few things under mvn jetty:run...: getRealPath gives me ./src/main/webapp the temp attribute is set to ./target/work and the location is ./target/classes While the war contains classes/work which is again different... I didn't manage to get jetty to serve contents from any other directory than the first one. Didn't try to run it on the standalone jetty, since I still don't know how to tell jetty to serve contents that is not under the webapp directory. Probably have to do something with the site map which I don't fully understand. Guess my main problem is that I don't have any experience in this field (jetty/lift) and thought it wouldn't be to difficult to port my website to lift and enhance it a little on the fly. To be continued... Job Honig On Nov 28, 12:52 am, Timothy Perrett
Re: [Lift] Re: How to get the servlet context
On Mon, Nov 30, 2009 at 4:14 PM, Timothy Perrett timo...@getintheloop.euwrote: Sometimes its an unavoidable fact that we need to store stuff on the file-system. Im not promoting inside the exploded war, but knowing your location and going from there can be a useful aid; its certainly something that i've done before with success. I'm all for putting stuff in a well-know location in the filesystem... and defining that well known location in the props file. Messing around with trying to figure out where the app server has exploded your WAR file (if it even has which is not AFAIK guaranteed) and putting files in there is a failure waiting to happen. Cheers, Tim On 30 Nov 2009, at 22:30, David Pollak wrote: Storing files inside the exploded WAR file is a tremendously bad idea. I don't think we should be helping a user do something that is going to continue to cause him pain. If he needs to upload images, etc. and then subsequently present them to the user, it's two tables in the RDBMS and a single stateless dispatch. All in all 40 lines of code and no pain. On Mon, Nov 30, 2009 at 2:08 PM, Marius marius.dan...@gmail.com wrote: Ahh so you want direct links to those files. Still you can do something else. Point your URI's from your page to a specific uri such as /myapp/serve/myimage.jpg. You intercept requests to myapp :: serve :: _ using a DispatchPF. The dispatch PF knows about your folder location (presumably from a config file) and reads myimage.jpg from that path on the file system. Hence you can read the File and send it to the client. I think you can use Lift's StreamResponse or you can build your own LiftResponse that returns a file using proper Content-Type. Another approach would be to use a reverse proxy server in front of your Lift application (this is a common production deployment model that server static content from frontend server not app servers), your Lift application could simply write files in the document-root folder hence would be seen by the proxy server and served to the client. I used in the past both options with no problem at all for use cases not so different than yours. Brs, Marius On Nov 30, 11:36 pm, jhonig al...@xs4all.nl wrote: Marius, I tried to create a link from the webapp dir to another location with rw-access, but that was not allowed... My conclusion was that you can't have symbolic links to locations outside the war. My problem is that there are three different locations that could all be interpreted as a root for looking up resources. I've found nothing suggesting one over the other, and none of them works. I assume there are more variables involved that I don't even know of. Job On Nov 30, 10:27 pm, Marius marius.dan...@gmail.com wrote: Ok I may be missing something essential from all this thread but why not use a folder from the user's home directory? If your app runs say under jetty OS user should heve read/write rights to write on the home user file-system. Even if not (although I haven't encountered the case) those rights can be granted by an admin. So why do you need special container allocated locations to write files? Br's, Marius On Nov 30, 11:18 pm, jhonig al...@xs4all.nl wrote: Hi Tim, Jeppe, and others who have replied... I have spent a few more hours, but there are just too many variables and I haven't been able to figure them out. I logged the various locations (running under a standalone jetty, not mvn jetty:run, and got this: INFO - TEMP = /tmp/Jetty_0_0_0_0_8080_tent. 0.1.SNAPSHOT.warvtra6b INFO - REAL = /tmp/Jetty_0_0_0_0_8080_tent. 0.1.SNAPSHOT.warvtra6b/webapp INFO - URL = file:/tmp/Jetty_0_0_0_0_8080_tent. 0.1.SNAPSHOT.warvtra6b/webapp/WEB-INF/classes/ I tried to access images, both from the HTML served to my browser and from Scala snippets. I used the following paths: Images/testimage.jpg work/Images/testimage.jpg classes/work/Images/testimage.jpg WEB-INF/classes/work/Images/testimage.jpg. The latter path is what I see in my .war file... I have no special filters. I tried to add entries to my site map, but none of them worked. About to give up. Hope somebody will help me. Job H. On Nov 28, 3:14 pm, jhonig al...@xs4all.nl wrote: Dear Tim and Heiko, I tested a few things under mvn jetty:run...: getRealPath gives me ./src/main/webapp the temp attribute is set to ./target/work and the location is ./target/classes While the war contains classes/work which is again different... I didn't manage to get jetty to serve contents from any other directory than the first one. Didn't try to run it on the standalone jetty,
Re: [Lift] Re: How to get the servlet context
Neil.Lv anim...@gmail.com writes:
Hi Jeppe,
I have the same question about the image folder.
Can you paste come example code ( or link ) that the Nginx how to
configure the mapping URL for images ?
Have a look at the nginx example: http://wiki.nginx.org/NginxFullExample
specifically
# serve static files
location ~ ^/(images|javascript|js|css|flash|media|static)/ {
root/var/www/virtual/big.server.com/htdocs;
expires 30d;
}
/Jeppe
--
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: How to get the servlet context
jhonig al...@xs4all.nl writes: Dear Tim and Heiko, I tested a few things under mvn jetty:run...: getRealPath gives me ./src/main/webapp the temp attribute is set to ./target/work and the location is ./target/classes While the war contains classes/work which is again different... I didn't manage to get jetty to serve contents from any other directory than the first one. Didn't try to run it on the standalone jetty, since I still don't know how to tell jetty to serve contents that is not under the webapp directory. Probably have to do something with the site map which I don't fully understand. I think you need to figure out how your URLs map to resources in 1) your app and 2) the tmp files you generate. If the files in 2) is outside your app context, you configure jetty to serve the files like this http://docs.codehaus.org/display/JETTY/Static+Content If the files in 2) is inside your app context, you need to make your Lift app handle the urls with sitemap and some code that can send the correct files based on the urls. I think these are the only two options if you are not using a frontend such as nginx (highly recommended). If you do use a frontend, you can configure all kind of url mappings there So perhaps a few more details on the required mappings could help... /Jeppe -- 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: How to get the servlet context
Use explicitly imports, thus avoiding these problems:
import some.package.{ClassOne, ClassTwo}
Cheers, Tim
On 28 Nov 2009, at 14:56, jhonig wrote:
I always avoided Eclipse because it usually got into my way, but with
the
lift habit of using wildcard imports I lose a lot of time tracing all
kinds of
definitions, so in this case I'm reconsidering...
--
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: How to get the servlet context
File tempdir = (File) config.getServletContext().getAttribute(javax.servlet.context.tempdir) 2009/11/27 jhonig al...@xs4all.nl Dear Heiko, According to the Servlet spec each webapp has got a private temporary directory. I cannot remember exactly how to get this, maybe ServletContext.getTmpDir(). Please take a look at the spec. I started reading the spec, but didn't find it yet. ServletContext doesn't have any obvious way to get to a temporary dir, but I assumed I could create one. Would probably need to tweak a security policy to be able to write to it, but that would be the next step. Job H. -- 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. -- Heiko Seeberger 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.
Re: [Lift] Re: How to get the servlet context
Job, This directory is managed by the servlet container and as far as I know there is little you can do to configure the location. If you use Tomcat you are able to specify CATALINA_BASE and it will be somewhere beneath that directory, I believe it is work/Catalina/localhost/WABAPP-NAME. Regarding serving images from there: Depending on the configuration of the servlet container WARs are not unpacked, hence there is no standard way to bring these images into your webapp. I think you will not be able to have the servlet container serve these images directly. But it should be easy to write a ServletFilter or something that will do it for you. Heiko 2009/11/27 jhonig al...@xs4all.nl Heiko, In the meantime, I found that solution as well... I tried it, and the default seems to be a work directory in target. I guess I can set another value for the attribute if I manage to convince jetty to do that for me. What I forgot to mention is that the directory is to contain images that are to be served by jetty... So it means the directory should be logically under webapp, but not in the war (of course). If I use a link from inside the war to some regular file system location, I'll probably run into the same problem as before. Any idea how to do this? Job H. On Nov 27, 6:56 pm, Heiko Seeberger heiko.seeber...@googlemail.com wrote: File tempdir = (File) config.getServletContext().getAttribute(javax.servlet.context.tempdir) 2009/11/27 jhonig al...@xs4all.nl Dear Heiko, According to the Servlet spec each webapp has got a private temporary directory. I cannot remember exactly how to get this, maybe ServletContext.getTmpDir(). Please take a look at the spec. I started reading the spec, but didn't find it yet. ServletContext doesn't have any obvious way to get to a temporary dir, but I assumed I could create one. Would probably need to tweak a security policy to be able to write to it, but that would be the next step. Job H. -- 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. -- Heiko Seeberger 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Heiko Seeberger 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.
Re: [Lift] Re: How to get the servlet context
Here's a nugget of information for you that will help (as I do something similar to what you want in one of my applications): val protectionDomain: ProtectionDomain = classOf[bootstrap.liftweb.Boot].getProtectionDomain() val location: URL = protectionDomain.getCodeSource().getLocation() Print the value of location, and that will get you headed in the right direction ;-) Moreover, if your using jetty, if there is a work directory next to where the war file is, jetty will automatically expand the war into that work folder... if not, it makes a temp directory in the relevant OS temp directory (/var/tmp on *nix OS) Godspeed. Tim. On 27 Nov 2009, at 21:49, Heiko Seeberger wrote: Job, This directory is managed by the servlet container and as far as I know there is little you can do to configure the location. If you use Tomcat you are able to specify CATALINA_BASE and it will be somewhere beneath that directory, I believe it is work/Catalina/localhost/WABAPP-NAME. Regarding serving images from there: Depending on the configuration of the servlet container WARs are not unpacked, hence there is no standard way to bring these images into your webapp. I think you will not be able to have the servlet container serve these images directly. But it should be easy to write a ServletFilter or something that will do it for you. Heiko 2009/11/27 jhonig al...@xs4all.nl Heiko, In the meantime, I found that solution as well... I tried it, and the default seems to be a work directory in target. I guess I can set another value for the attribute if I manage to convince jetty to do that for me. What I forgot to mention is that the directory is to contain images that are to be served by jetty... So it means the directory should be logically under webapp, but not in the war (of course). If I use a link from inside the war to some regular file system location, I'll probably run into the same problem as before. Any idea how to do this? Job H. On Nov 27, 6:56 pm, Heiko Seeberger heiko.seeber...@googlemail.com wrote: File tempdir = (File) config.getServletContext().getAttribute(javax.servlet.context.tempdir) 2009/11/27 jhonig al...@xs4all.nl Dear Heiko, According to the Servlet spec each webapp has got a private temporary directory. I cannot remember exactly how to get this, maybe ServletContext.getTmpDir(). Please take a look at the spec. I started reading the spec, but didn't find it yet. ServletContext doesn't have any obvious way to get to a temporary dir, but I assumed I could create one. Would probably need to tweak a security policy to be able to write to it, but that would be the next step. Job H. -- 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. -- Heiko Seeberger 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. -- Heiko Seeberger 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. -- 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.
