On Mon, Nov 30, 2009 at 4:14 PM, Timothy Perrett <[email protected]>wrote:
> 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 <[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]> > <liftweb%[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]<liftweb%[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]<liftweb%[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]<liftweb%[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]<liftweb%[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]<liftweb%[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.
