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>
> > > > > > > > .
> > > > > > > > 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
> > > > > > 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.
> > > > > > 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.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
