Serving dynamic (cfm, cfc, jsp) and static (htm, jpg, css) content from the WebSphere J2EE Web Application Server using the IBM HTTPD Web Server can sometimes be challenging. I've often recieved questions on the seperation of content over the years from people using ColdFusion MX on WebSphere, although ColdFusion just happens to be incidental to the matter.

This problem description explains:

In summary, the issue is getting Apache configured to serve web resources and having CF process CFM files. The only way we could get it to work was to put all files under Webshphere, which means we can't deploy HTML or use Apache for serving images, css, etc...

We have a root context of /. We tried putting the CFM files under the Apache home directory with the HTML, as you would in JRun. We also tried splitting them with the CFM files under the websphere home and HTML under Apache home. Neither one would work for us.


The separation of static and dynamic content when using WebSphere (regardless of ColdFusion) is a known limitation for WebSphere, unlike JRun. By default, WebSphere will not serve static content from the EAR/WAR root directory unless the fileServingEnabled EAR attribute is turned on in the ibm-application-ext.xmi config file (a proprietary IBM extension to the J2EE spec, in the EAR/META-INF directory) or the ibm-web-ext.xmi config file in the WAR, but even then IBM describes that practice as a security risk. If that attribute were turned on then all static and dynamic content could reside in and be served from the EAR/WAR root.

The IBM recommendation to me has been to place static content in the IBM HTTPD (a proprietary product built on the Apache webserver) document root and dynamic content in EAR/WAR root. In fact, as far as I know, dynamic content cannot be placed outside the WebSphere EAR/WAR root, jsp or cfm. Your dynamic content can use absolute or relative URLs when referring to static content which the HTTPD server will know how to resolve. If the HTTPD server cannot resolve static content, then it is entirely an IBM HTTPD issue, not one of the J2EE Web Application.

So say the HTTPD server gets a request for /cfusion/index.cfm, then the /cfusion context root and the .cfm extension are triggers to handle the request for the J2EE application. If the dynamic output refers to an image, say then assuming /foo is not a context root then HTTPD will attempt to resolve image bar.jpg in the directory /foo in the HTTP docroot. If fileServingEnabled is true, and the image exists in the EAR/WAR root instead, then the image can be resolved at /cfusion/foo/bar.jpg for example.

In my experience, WebSphere is case-senstive to the URLs even on Windows. So a request for /cfusion/INDEX.cfm may not be resolved to the file index.cfm in the EAR/WAR root, and the same might be true for static content where /foo/BAR.jpg may not resolve to /foo/bar.jpg.

I haven't tested using a / context root, but I assume that the WebSphere J2EE container would attempt to resolve /foo/bar.jpg as being in the EAR/WAR root, and when fileServingEnabled is off then WebSphere will return a 404 whether or not the jpg is in that EAR/WAR root and the HTTPD server will not attempt to resolve the content.

Related WebSphere Documentation:



IBM Extension to J2EE: ibm-application-ext.xmiibm-application-ext.xmi: fileServingEnabled