App runs locally but returns 404 running on cloudbees

Question

My app ([URL]) is not responding. I have gone through the recommended steps on your site.

I have deployed this war to my local tc-server and everything is working there (/people-server/rest/persons/). I would expect to get some xml back from [URL]/people-server/rest/persons/.

Please advise

Darren Leung

Answer 1

Your app is actually responding to http://[URL]/_stax/status, which implies the container is able to receive and handle requests properly.

Since your app is returning 404 for /people-server/rest/persons path requests, this implies that there are no Servlets currently loaded by the container to handle those requests. There are two main reasons that your app may not have servlets configured at runtime:

1. You have not configured your app with Servlets properly to handle these requests (this is typically done via servlet and servlet-path entries in WEB-INF/web.xml)
2. There was an error that occurred during the startup sequence of your app that prevented the container from loading your configured Servlets.

To determine if there is an error, the first thing you should check is the logs for your app. Since you didn't post any errors, I'll assume that you checked the logs already and did not find any errors.

This leaves you with the scenario that you don't have any Servlets configured to handle the requests. After seeing your URL, I noticed that it is prefixed by /people-server, which looks suspiciously like a context-path prefix you may be using in your locally configured TC server. Since apps deployed on CloudBees run at the root context-path, I tried using the following URL and see that it is indeed responding: [URL]/rest/persons/

This implies that you do have a Servlet configured for handling /rest/persons/ paths, which means you are encountering a slight difference in URLs expected in your local environment vs your deployed environment.

If you want this Servlet to be available at /people-server, you will need to update your web.xml to use this prefix for the path used by your REST Servlet. Alternatively, you can deploy the app as an EAR file with an application.xml that uses a context-path of /people-server for your webapp archive.

Answer 2

As a general rule - 400 type errors (eg 404 in this case) indicate a problem with the app almost always - and are typically related to path errors and mapping.

500 type errors mean there is an unhanded error in the application, this is as per:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Some causes of them could be if the application is slow to start, there can be a short period of time where there are some errors, 504 if the application (all instances of it) are very very slow (too slow).

If there is a persistent 502 happening this can indicate a platform problem in some cases (ie requests are not reaching your application).

You can often see errors in your apps log (bees app:tail will stream this - or use the console).

Answer 3

If your app uses JAX-RS to serve rest content on a jboss ("JavaEE 6 Web profile") container, you need to enable container support for this feature. Just add this servlet declaration to your web.xml

<servlet>
    <servlet-name>jax-rs</servlet-name>
    <servlet-class>javax.ws.rs.core.Application</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>jax-rs</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

Your IDE may warn javax.ws.rs.core.Application is not a servlet, and that's indeed a strange detail from JAX-RS API, but that's the correct class to be used.