Apache httpd and tomcat (on port 80)

t1mm

Hi all,

Pulling my hair out on this one, and hoped one of you couuld help. I've written a Java Web App (Spring MVC), and it's deployed to a tomcat server (running on the default port 8080). I also have apache httpd running on port 80.

I will require both PHP and Java applications running on port 80 on this server, and so I have setup mod_proxy to act as an intermediary between httpd and tomcat.

I have a VirtualHost setup for mysite.com. I'd like it to actually direct to localhost:8080/myApplication. The VirtualHost contains the following lines:

        # Proxy for Tomcat
        ProxyPass / http://127.0.0.1:8080/myApplication/
        ProxyPassReverse / http://127.0.0.1:8080/myApplication/

This all works fine for the root directory. However, mysite.com/aboutus (for example) does not resolve correctly, and returns a 404. mysite.com/myApplication/aboutus doesn't work either unfortunately.

Can anyone offer any solace on the matter?

As an aside, in this type of setup where would you recommend storing static resources? I've heard that apache httpd is quicker at storing them and it might be worth locating them on that side, rather than packed in the .war sitting on tomcat.

Would greatly appreciate any input on the matter - spent almost a day tinkering with this now!

Cheers,

t1mm

EDIT: Running Ubuntu 12.04LTE with a standard lamp^ and tomcat7 install.

Colonel Panic

What does apache log when you get a 404 for the aboutus page?

I've long since dumped Apache for Nginx, but from memory, those lines look okay. What's the rest of the virtualhost entry?

t1mm

<VirtualHost *:80>
        ServerAdmin me@mydomain.com
        ServerName mydomain.com
        ServerAlias www.mydomain.com

        # Proxy for Tomcat
        ProxyPass / http://127.0.0.1:8080/myApp/
        ProxyPassReverse / http://127.0.0.1:8080/myApp/
</VirtualHost>

There doesn't seem to be anything in error.log, but access.log contains: "GET /myApp/aboutus 404".

Nightmare!

Colonel Panic

Is Tomcat only listening on localhost? If you ssh into the server and forward 127.0.0.1:8080 to some local port, does [local ip]:[local port]/myApp/aboutus work?

t1mm

I can access it from mydomain.com:8080 from anywhere. Terribly sorry to trouble you further Colonel, but how would I go about doing that?

Colonel Panic

If you can access mydomain.com:8080 from anywhere, then can you access mydomain.com:8080/myapp/aboutus from anywhere?

I'm asking to eliminate issues with mod_proxy.

Don't worry about the ssh thing.

You could try:

ProxyPass / http://0.0.0.0:8080/myApp/
        ProxyPassReverse / http://0.0.0.0:8080/myApp/

Im not crazy about this approach though, I prefer to have implementation details of my web apps hidden behind the proxy which I have listening only on localhost or a Unix socket.

t1mm

Hi Colonel,

I think I have finally solved the problem actually. Like an idiot, I was actually visiting a page that didn't exist in the Java App. All solved now - the VHost and Proxy information I originally posted do the trick!

Would you generally host the resources (images/css) on the apache server, or leave them packaged in the .war on tomcat?

Thank you very much for your patience

Colonel Panic

I thought that might be the case, it's why I suggested eliminating the mod_proxy stuff from the equation!

Regarding the static file hosting. I can't speak about Tomcat hosted apps specifically, but I try to host static data on the front facing webserver or something like S3 for my Node.js and Python based apps.

Maybe see what performance is like with the resources in the .war? Or someone who's got more Tomcat knowledge than me might have some suggestions.

t1mm

Do you know how I could go about using relative file paths to point to the apache server given that the links will be inside JSP files?

EDIT: Sorry, I didn't properly read your answer there. I'll look into it some more, thank you very much again for your help Colonel ^^

Colonel Panic

To be honest, I don't. The way I deal with is via development, testing and production configurations which help resolve paths to static data like css, images and template files. I'm not sure this is the "right" or "best" way.

I know very little about JSP I'm afraid other than at a high level.

chrislad

If you're using Spring, you can use this type of code in the JSP

<img src="${pageContext.request.contextPath}/static/css/images/spring-logo.jpg"
        alt="" title="" border="0">

That will sorted you out.

Defined like this for the folder structure

context:component-scan base-package="controllers, email"></context:component-scan>
<mvc:annotation-driven></mvc:annotation-driven>
<mvc:resources location="/resources/" mapping="/static/**" />
    //defined within the dispatcher servlet xml file

    <security:http use-expressions="true">
            <security:intercept-url pattern="/static/**" access="permitAll" />
            <security:intercept-url pattern="/images/**" access="permitAll" />
    //defined within the security-context.xml file

cython

t1mm wrote: »

As an aside, in this type of setup where would you recommend storing static resources? I've heard that apache httpd is quicker at storing them and it might be worth locating them on that side, rather than packed in the .war sitting on tomcat.

As far as this section is concerned, I would say that your target deployment approach is potentially as important as performance. For example, if this is an in house application or similar whereby deployment is handled by people familiar with development and the application architecture/structure, then it may be ok to keep the files hosted outside the war. However if this is something you want to ship to a client, I would be trying to keep as much as possible within the war file to simplify deployment. There may be a small performance hit to this, but since most war containers explode the war file on deployment (even if just in a temp directory) I wouldn't expect this to be too significant, and having a single deployable can be invaluable.

Where I work we have several applications running on WebSphere and Weblogic, and inevitably the more mature products which have minimal resources kept outside the ear file tend to have the least deployment-related issues. By contrast, those newer applications with a lot of environment-specific config files outside the deployment archive (and these need to be outside, due to varying deployment configs), tend to be more prone to issues related to this. The flip side of these being less mature applications though means that their configuration requirements tend to change more often.