What is your OS? If this a *nix - then you have make sure that Web-INF is readable for the world, this is NOT good .On the other hand you could just create a soft link to whatever they have there... Evgeny
On Wed, Jun 17, 2009 at 9:20 PM, Susan G. Conger <sus...@bfcassociates.com>wrote: > I started with the authors of the tool app and they said it was a tomcat > limitation. Basically can't be done. So I figured I would try the list > before I took their word for it. > > Yes, I use the tool to modify the template files. But that is basically > just editing html using the tool. When the tool app builds my app it > copies > everything into the classes directory. So that everything looks like one > big Java class under the tool app. So my thought is that my images and > javascripts should go in here so I can have everything together and make > maintenance easier. I check everything the tool app builds into subversion > so I can have some source control. > > Thanks, > Susan > > > -----Original Message----- > From: Pid [mailto:p...@pidster.com] > Sent: Wednesday, June 17, 2009 2:09 PM > To: Tomcat Users List > Subject: Re: Serving images from classes directory > > Susan G. Conger wrote: > > The template files are in the classes directory. This is a web app that > is > > deploying it's own web app. So it is rather convoluted. The web app > that > > gets deployed is my web app while the web app doing the developing is the > > third party tool. > > > For reference then, we'll call the first one the 'tool app'. > > So are you actually editing the template files yourself, or are you > using the tool app to edit the template files? > > Where in your app do the modified template files end up, and are they > copied individually? > > > The thought also occurs that the authors of the tool app might be the > people you really want to be talking to about this. > > p > > > > > Thanks, > > Susan > > > > -----Original Message----- > > From: Pid [mailto:p...@pidster.com] > > Sent: Wednesday, June 17, 2009 1:29 PM > > To: Tomcat Users List > > Subject: Re: Serving images from classes directory > > > > Susan G. Conger wrote: > >> Thanks Tim. I don't have control during build because that is done by > the > >> third party tool. I am not going to mention their name. I was hoping > > that > >> this would be easy. You know a servlet mapping in the web.xml file that > >> would allow me to just map the directory/file type and I could just put > > that > >> in my html. Since I can't use jsp everywhere I need the images. Again > I > > am > >> tied into their system and they have stuff in html files that they > create. > >> I edit the html template files they have to add my images and > javascript. > >> I use their environment to create/edit/build the web application. > > Underneath > >> I have tied in netBeans the best I can so I can debug their stuff. But > > that > >> has issues too. > > > > If you can edit the template files, can't you include images in the same > > place as the templates? > > > > p > > > > > > > >> Thanks, > >> Susan > >> > >> -----Original Message----- > >> From: Tim Funk [mailto:funk...@apache.org] > >> Sent: Wednesday, June 17, 2009 1:07 PM > >> To: Tomcat Users List > >> Subject: Re: Serving images from classes directory > >> > >> If the images are physical images in the classes directory - you have a > >> few options. > >> > >> 1) At build time - move (or copy) the files from the classes directory > >> to somewhere more sane that the default servlet can access > >> 2) Write a filter the detects these images that live in the classes dir, > >> and then forwards to the images. (You need to be careful with this one) > >> > >> For # 2 - it would look something like this: > >> doFilter(...) { > >> String p = request.getServletPath(); > >> if (p.matches("/magic_prefix/[\\w]+\\.gif$")) { > >> String np = request.getServletPath().replaceFirst(".+/", ""); > >> request.getRequestDispatcher("/WEB-INF/class/more/cowbell/" + np) > >> .forward(request, response); > >> } else { > >> chain.doFilter(...); > >> } > >> } > >> > >> > >> -Tim > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
