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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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.war____vtra6b > > > > INFO - REAL = /tmp/Jetty_0_0_0_0_8080_tent. > > > > 0.1.SNAPSHOT.war____vtra6b/webapp > > > > INFO - URL = file:/tmp/Jetty_0_0_0_0_8080_tent. > > > > 0.1.SNAPSHOT.war____vtra6b/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 <[email protected]> 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 <[email protected]> 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 = 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 <[email protected]> > > > > > > > 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 > > > > > > > <[email protected]> > > > > > > > wrote: > > > > > > > > File tempdir = (File) > > > > > > > > config.getServletContext().getAttribute("javax.servlet.context.tempdir") > > > > > > > > > > 2009/11/27 jhonig <[email protected]> > > > > > > > > > > > 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 [email protected]. > > > > > > > > > To unsubscribe from this group, send email to > > > > > > > > > [email protected]<liftweb%[email protected]> > > > > > > > > > . > > > > > > > > > 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 [email protected]. > > > > > > > To unsubscribe from this group, send email to > > > > > > > [email protected]. > > > > > > > For more options, visit this group > > > > > > > athttp://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 [email protected]. > > > > > > > To unsubscribe from this group, send email to > > > > > > > [email protected]. > > > > > > > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
