Susan G. Conger wrote: > I started with the authors of the tool app and they said it was a tomcat > limitation. Basically can't be done.
What is 'it', precisely? If they control the tool app then why can't they specify a location to place scripts, stylesheets and images, so that they output in a predictable place in your webapp? > So I figured I would try the list before I took their word for it. You're not meant to _directly_ access anything in WEB-INF/. It's protected, and deliberately so, as it has stuff you don't want users to access. You *can* put stuff in there and write some code to access it and deliver it on request, but there's not a lot of point in doing so if you can just put the data in question somewhere more accessible. Typically, your webapp would look like (something) this: appname/index.html appname/thing.jsp appname/images/logo.gif appname/styles/layout.css appname/scripts/common.js appname/WEB-INF/web.xml appname/WEB-INF/classes/com/my/app/AppServlet.class appname/WEB-INF/lib/commons-logging.jar Anything you put under /classes isn't going to be available directly to the user if the server is a properly functioning Servlet container. Doesn't stop you putting things elsewhere though. > 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. Which classes directory? The one in the tool-app, or the one in your generated webapp? If it copies 'everything' why can't it copy images somewhere into the generated app too? > So that everything looks like one big Java class under the tool app. That doesn't make a great deal of sense. You're saying that there's a file called (something like) BigBunchOfTemplates.class in WEB-INF/classes ? > 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. Let's see if my understanding is accurate first. p > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
