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.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 <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 =
> 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.com<liftweb%2bunsubscr...@googlegroups.com>
> <liftweb%2bunsubscr...@googlegroups.com<liftweb%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.com<liftweb%2bunsubscr...@googlegroups.com>
> .
> > > > > > > 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 lift...@googlegroups.com.
> > > > > > > To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com>
> .
> > > > > > > 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 lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com<liftweb%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.
