On Sat, Aug 10, 2013 at 12:02 PM, Mark Eggers <its_toas...@yahoo.com> wrote:
> Hopefully the original poster is just emulating what will be in > production. In other words, rather than having an Apache HTTPD server with > the static files on his development machine, as well as connecting Apache > HTTP and Tomcat with AJP, he's using a shortcut to make sure all the URLs > work. > > If not, then yes, security will be a potential issue if you're not > careful. However, if the WAR file containing /common only contains static > material, there may not be much risk. > > Agreed. It would be the best to install Apache on the local machine too, so you can successfully emulate the production environment. Sadly, Eclipse does not work the way you think it does. Eclipse does not > really use CATALINA_HOME/webapps when it deploys applications. It uses the > following: > > workspace/.metadata/plugins/**org.eclipse.wst.server.core/** > tmp[n]/wtpwebapps/[context-**name] > > Yes. Workspace metadata directory is the default option out of three: 1) Use workspace metadata (does not modify Tomcat installation) 2) Use Tomcat installation (takes control of Tomcat installation) 3) Use custom location (does not modify Tomcat installation) (You can get to this setup in Servers tab by double clicking on your Tomcat installation). I prefer the second option, using Tomcat installation directory. > If you look in that directory, you'll see only the applications you've > deployed via Eclipse (no default ROOT application, no examples, no manager > application, nothing). > > The cleanest way around this is to deploy everything from within Eclipse. > > You could copy the static files to that location, but I don't know if > tmp[n] changes. > > You could also set up an Apache HTTPD server, copy the files there, and > link the two with AJP. While that sounds a bit more complicated, it's not > really that difficult. This would have the advantage of more closely > emulating the production environment as well. > > The best of course is to replicate the setup you have on the production systems (not that hard). Here's another alternative that involves just Eclipse+Tomcat only: - Make sure you don't have applications deployed on Tomcat within Eclipse (otherwise you don't be able to make changes to the Tomcat configuration within Eclipse) - Change Tomcat configuration to use "Tomcat installation (takes control of Tomcat installation)", i.e. the middle option in Tomcat configuration - Create new "Dynamic Web Application" project (static web project would not work since it doesn't deploy to Tomcat within Eclipse), e.g. call it "static", as part of the creation don't use "src" and select "/" for context root - Put all your static content into that project, e.g. "commons/images/tomcat.png" - Update urls for the static content, e.g. <img src="/commons/images/tomcat.png" /> - Deploy both applications to Tomcat - Your static content will now be successfully deployed to Tomcat as "/" I am curious to find out about the actual deployment strategy to Tomcat/Apache setup. What is your official deployment strategy? How do you successfully break static and dynamic content? Hope that helps, Neven
