Tridion CWA 2011 Binaries Return 404 Until Refreshed

Question

My client is having an issue after upgrading from CWA 1.5 to CWA 2011 running on WebSphere. The issue is that any binary resources requested return a 404. When the request is resubmitted (i.e. the page is refreshed/reloaded), then they load.

I have no access to their environment and have to get all the config files via third party. I was wondering if anyone has any ideas off the top of their heads on what could be causing these 404s on binaries?

Howbeit

Answer 1

For WebSphere 7, the default servlet is known as the FileServlet, and so the following should work:

<servlet>
<servlet-name>FileServlet</servlet-name>
<servlet-class>
com.ibm.ws.webcontainer.servlet.SimpleFileServlet 
</servlet-class>
</servlet>


<servlet-mapping>
  <servlet-name>FileServlet</servlet-name>
  <url-pattern>*.css</url-pattern>
</servlet-mapping>
<servlet-mapping>
  <servlet-name>FileServlet</servlet-name>
  <url-pattern>*.jpg</url-pattern>
</servlet-mapping>
<servlet-mapping>
  <servlet-name>FileServlet</servlet-name>
  <url-pattern>*.js</url-pattern>
</servlet-mapping>
<servlet-mapping>
  <servlet-name>FileServlet</servlet-name>
  <url-pattern>*.gif</url-pattern>
</servlet-mapping>

Auditory

Answer 2

Starting with Websphere 6.1, IBM changed the behavior of filters and these will not be executed if the URL you're calling doesn't actually exist on the server.

This means that a request for /somefile.png that is still on the DB will result in a (technically correct) 404 but completely not what you expect with a CWA enabled web application.

The solution is to make the filter invoke on a request without a servlet mapping and you should be able to do the following in the WebSphere Admin Console:

1. Click Servers -> Server Types -> Websphere Application Server -> -> Web Container Settings -> Web Container
2. Under additional settings click on custom properties
3. On custom properties page, click New and then enter "com.ibm.ws.webcontainer.invokefilterscompatibility" as the property name and "true" as the value
4. Save the update and restart the server

Auditory

Answer 3

It is a long time since I have used CWA, but IIRC it serializes the binaries to disk on request, and caches them for future requests. It sounds like that process is just taking too long, so you get a 404 the first request for a binary. I have heard of this before on WebSphere, are you sure it was not happening with the old CWA also?

If the issue continues, I suggest contacting SDL Customer Support.

Cominform

Answer 4

In the cd_cwa_conf.xml file, you can also add the following parameter:

<configuration>
... 
   <!-- Number of seconds to wait for the default Servlet to pick up changes on the file-system -->
    <file-synchronization delay="..." />
...
</configuration>

As Chris has said, the first time a binary is requested then the file is serialized and cached on the disk. If the process is too long then the app server will return a 404.

With this parameter, the system will wait for few seconds (ie the specified value) before accessing the file.

We had the same issue with a Tomcat server and this has fixed the pb.

Castellanos

Not anymore Seb :) That feature has been taken out of TDF in the last CWA 2011 code. Nowadays, instead of doing that we are explicitly mapping the DefaultServlet to the URL pattern in the web.xml and apparently that fixes the 404 issue. Note however, the problem described above is not referring to that behaviour. The issue above is 'getting a 404 with every request'. The one you and I refer to is 'getting a 404 on the first request only'. – Forlorn

I posted another answer, because I too was confused by the actual meaning of the question... please see above – Forlorn

Answer 5

I think there is a bit of confusion in what exactly the question is about. So Nick is explaining that a first request on a binary results in a 404. Any subsequent requests do serve the binary as expected. Therefore, the answer Elena gave is not really the fix for this issue, although she is very correct is saying that that particular setting has to be made indeed in WebSphere.

The answer for issue 'getting a 404 on the first request only' is having an explicit mapping in the web.xml file on each URL pattern binary type to the Default Servlet. This is described in http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_CWA_10/task_C1FECE85AD5E4F0BB3957C4516D7E2AC, bullet #6:

 <servlet-mapping>
    <servlet-name>default</servlet-name>
    <url-pattern>*.jpg</url-pattern>
 </servlet-mapping>

Documentation states this fixes JBoss, Tomcat, but I have also seen it fix WebLogic. I hope it does fix WebSphere too. Please let us know.

Dobbin

FYI there is a limitation with Tomcat 7. See my answer below. – Patrol

Answer 6

Be careful if you are using Tomcat 7 (and probably latest versions of Tomcat 6). There is a limitation within the way web.xml files are merged.

I don't know exactly why but you CAN'T define several mappings to the default servlet. You can have only one mapping entry for this servlet.

Maybe in relation with this: https://issues.apache.org/bugzilla/show_bug.cgi?id=50026

By the way, you can bypass this limit by redefining also the default mapping.

Ex: The following doesn't work with Tomcat 7.0.33. All resources are in 404 error.

<servlet-mapping>
  <servlet-name>default</servlet-name>
  <url-pattern>/worldwide/binaries/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
  <servlet-name>default</servlet-name>
  <url-pattern>/france/binaries/*</url-pattern>
</servlet-mapping>

The following works perfectly

<servlet-mapping>
  <servlet-name>default</servlet-name>
  <url-pattern>/worldwide/binaries/*</url-pattern>
  <url-pattern>/france/binaries/*</url-pattern>
  <url-pattern>/</url-pattern>
</servlet-mapping>

Hope it help.

Castellanos