Mysterious 404 errors in ATG J2EE applications

Often during development of an ATG J2EE application one will suddenly run into a 404 error. 404 means that the server could not locate the requested page . But often when one sees this error it is not because ATG could not locate the requested page but because it could not generate the page due to some sort of error which unfortunately ATG sometimes does not log. The error could be one of several.

  1. The J2EE application that contains the page did not properly start or was not started at all. One can check if the application was started either by looking in the ACC under the J2EE Deployment Editor or checking in the dynamo.log if the application was started and/or listed in the list of modules at start up.
  2. A runtime exception occurred in one of the droplets that were invoked in the page. Unfortunately ATG does not log the runtime exception, it is swallowed up somewhere. The best way to debug this is to start removing parts of the JSP page until you discover which part of the page is causing the 404.

Windows hosts file not working

On Windows you can manually match hostnames to IP addresses using the hosts file located in C:\WINDOWS\system32\drivers\etc. An example of a hosts file:

127.0.0.1       localhost
#10.22.1.18     foo foo.bar.ca
16.17.18.19     toronto
16.17.18.125    boston

If you find that the contents of the hosts file are not being picked up by Windows it might be because the file is corrupted though the corruption is not evident in your editor. The best thing to do is to delete or move that file and create a brand new hosts file and hopefully the contents of this hosts file will be picked up by Windows.

ATG forms do not work if action is an HTML page

When creating forms that are to interact with ATG form handlers, one cannot use an HTML page as the action. If one does then the ATG form handler will not be invoked.

For example, this form will not invoke the ATG form handler.

<form name="test" action="test.html" method="get">
  Name: <input type="text" bean="/TestFormHandler.name">
  <p><input type="submit" bean="/TestFormHandler.submit">
</form>

However this form will.

<form name="test" action="test.jhtml" method="get">
  Name: <input type="text" bean="/TestFormHandler.name">
  <p><input type="submit" bean="/TestFormHandler.submit">
</form>

Internet Explorer form does not invoke ATG handler

In Internet Explorer if you have a form that has only a single line text input and if you press Enter to submit the form instead of pressing the submit button then the ATG handler for this form will not be invoked. Instead the form will act like a regular HTML form.

To get around this problem on Internet Explorer one must explicitly call the handler using a hidden input tag.

Here is an example of a simple form that illustrates this problem. The action of this form is to go to wrong.jhtml but if the ATG handler is invoked then the request is redirected to right.jhtml.

<form name="test" action="wrong.jhtml" method="get">
  Name: <input type="text" bean="/TestFormHandler.name">
  <p><input type="submit" bean="/TestFormHandler.submit">
</form>

Here is a screenshot of this form.

test form with only one input field

When I press Enter I go to the wrong page, i.e. wrong.jhtml, because the handler is not invoked.

example of a form working incorrectly

When I press the Submit button I go to the right page, i.e. right.jhtml, because the handler is invoked.

example of a form working correctly

To fix this I add this line within the form of testForm.jhtml.

  <input type="hidden" bean="/TestFormHandler.submit">

I also add this getter, which does nothing and may not be necessary for later versions of ATG, in the form handler.

  public String getSubmit() { return null; }

After doing this when I press Enter I go to the right page.

Note that with a form that has more than one input field this is not a problem.

test form with two input fields

The source for this example can be downloaded here.

Configuring Bugzilla

  1. Modify <bugzilla>/localconfig to have the operating systems, severities, platforms,etc. that you want.
  2. Modify <bugzilla>/template/en/default/bug/create/create.html.tmpl to have the look you want for creating bugs.
  3. Modify <bugzilla>/template/en/default/bug/edit.html.tmpl to have the look you want for editing bugs.
  4. Other files that could be considered for modification under the directory <bugzilla>/template/en/default/:
    • bug/show-multiple.html.tmpl – list bugs in long format
    • global/field-descs.none.tmpl – field descriptions
    • list/edit-multiple.html.tmpl – edit multiple bugs
    • list/table.html.tmpl – list bugs in short format
    • pages/fields.html.tmpl – description of fields
    • pages/bug-writing.html.tmpl – help page for writing bugs
    • search/form.html.tmpl – help page for searching for bugs
    • search/search-help.html.tmpl – help page for searching for bugs
  5. Go to the <bugzilla> directory and run perl checksetup.pl.

To learn more, Template Customization.

Serial Version UID

It is simple to make a class serializable, just have it implement the java.io.Serializable interface. However it is not easy to support the serialized form forever.

One issue is the serial version UID. Every serializable class has a unique identification number associated with it. If you do not specify the identification number explicitly by declaring a private static final long field named serialVersionUID, the system automatically generates it by applying a complex deterministic procedure to the class… If you change [the class] in any way … the automatically generated serial version UID changes. If you fail to declare an explicit serial version UID, compatibility will be broken.

Bloch, Joshua. Effective Java. p. 214

To generate the serial version UID for a class use the serialver tool which comes with the Java SDK. The serialver tool returns the serial version UID for one or more classes.

Example:

$ serialver -classpath 'build;C:/foo/classes.jar' com.bar.FooMessage

or

> serialver -classpath build;C:\foo\classes.jar com.bar.FooMessage

An even easier way to generate the serial version UID is to use the Eclipse IDE. If your class implements the java.io.Serializable interface and it does not have a serial version UID then Eclipse will give a warning about this next to the class name. If you click on the warning you can choose the option “Add generated serial version ID.”

Note, currently there is a bug with Eclipse and generating the serial version UID. When attempting to generate a serial version UID you will see a dialogue window which says “Computing serial version ID….” and “Starting virtual machine…”. Unfortunately this hangs and you are forced to kill your Eclipse IDE. I started seeing this bug yesterday after installing some JDBC plugins and the GEF plugin, I’m not sure if it’s related to that. I tried disabling the plugins but I still see the problem. Before I wasn’t having this problem.

user-defined property type gotcha’s

When you create a user-defined property type there are two things to keep in mind.

  1. The user-defined property should be transient.
  2. The user-defined property must have a data-type defined or the item that contains this property will not be displayable in the ACC.

Here is an example of a user-defined property type.

<item-descriptor name="foo" display-property="name" display-name="Foo">
  
 <property name="bar" property-type="com.betweengo.Bar" data-type="string"/>
 
 <table name="foo" type="primary" id-column-names="id">
  <property name="id" data-type="string"/>
  <property name="name" column-names="name" data-type="string"/>
 </table>
 
</item-descriptor>

To learn more, User-Defined Property Types. Note that in the ATG documentation the example for the user-defined property does not define a data-type. This is probably a documentation bug.