Documentation Archive Developer
Search
Table of Contents Previous Section

Problems With Compiled Applications

 Running compiled applications exercises more features of the WebObjects framework and development environment. Before attempting to troubleshoot a problem with running a compiled application, make sure you can run a simple scripted application.

Problem

A simple compiled application won't run properly.

Checklist

  1. If the program is a Java program, check the CLASSPATH environment variable.

    Java programs sometimes fail when the CLASSPATH is set incorrectly because they are not able to access necessary classes at runtime. Your CLASSPATH should include the directories NeXT_ROOT/NextLibrary/Java and NeXT_ROOT/NextLibrary/JDK/lib/classes.zip.

  2. Make sure the executable has been built.

    On the HP-UX platform, examples are not installed built. You must build them yourself before you can run them. To compile an example, cd to the example's project directory and type make. For example:

    > cd <DocRoot>/WebObjects/ObjectiveC/HelloWorldCompiled
    > make

Problem

A compiled application won't autostart.

Checklist

  1. Verify that autostarting is enabled on your system.

    If you can run the example by hand but cannot autostart it, check the section Post-Installation Steps for your operating system and make sure you've performed all of the necessary steps.

    Corrective actions:
    Check your system for the file NeXT_ROOT/NextLibrary/WOAdaptors/Configuration/WebObjects.conf. This file is called the public configuration file, and it is used to balance the processing load among multiple instances of the same application. Even if you're not doing load balancing, if you've used the Monitor application to administer your site, a public configuration file exists. As a safety measure, if the public configuration file exists, applications do not autostart. You should start all applications manually. You can learn more about the public configuration file and the Monitor application in the document Serving WebObjects.

    If you're using WebObjects on Windows NT with one of the Microsoft web servers (IIS or PWS), you must install WebObjects in the root directory for autostarting to work properly. That is, your NEXT_ROOT must be something like C:\. If you installed WebObjects using the default NEXT_ROOT of C:\NeXT, uninstall WebObjects and reinstall it.

    Problems autostarting applications are often a result of the owner of CGI processes not being able to access resource files in NEXT_ROOT. The Post-Installation Steps tell you how to solve this problem for your particular operating system.

  2. Make sure the correct application is running.

    When WebObjects receives a request for a particular application, it first looks for running instances of that application, then it looks for an executable file that it can start up. If these two strategies fail, WebObjects starts an instance of WODefaultApp and assigns it the task of handling requests for the specified application. So, if WebObjects can't find the executable for your compiled application, it will start the default application, which unfortunately won't have access to all the compiled logic of your application.

    Corrective actions:
    Check the processes running on the server to discover if your compiled application is running or if a default application is running in its place. If a default application is running in place of your compiled application, kill the default application.

    During development, it's best to run your application from Project Builder's launch panel or from a command shell window. This way, you'll be able to see all debugging output in the launch panel, and you'll find it easier to kill and restart your application. It's always best to kill and then restart your application whenever you add new components to it during the development process. Before starting the application, check to see if an autostarted version of the application is already running. If one is, kill it before manually starting a new instance of the application.

Problem

The DodgeDemo application won't run.

Checklist

  1. Make sure the application was correctly installed and compiled.

    The DodgeDemo application must be compiled before you can run it. In addition, you must create the DodgeDemo database (scripts are provided) and install the database model file that is compatible with your database server as described in "Setting Up the Sample Databases."

    Check the DodgeDemo directory for an directory named DodgeDemo.woa. This is the WebObjects application wrapper. Check the wrapper for an executable file. If the wrapper or the executable doesn't exist, build the DodgeDemo application.

    On Solaris and HP-UX, you need to build DodgeDemo with the correct client libraries and adaptor. Before you build, add the appropriate adaptor framework to the FRAMEWORKS makefile variable. Then uncomment the following line in the Makefile.preamble to link the appropriate client libraries:

    include $(MAKEFILEDIR)/pdo-eoadaptor-linking.make

    If DodgeDemo compiles and runs but can't access data about the various models of cars, it's probably because the application can't communicate with the database server.

Problem

A WebObjects application won't connect to the database server.

Checklist

  1. Check that your database server itself is operating correctly.

    Check that the client libraries for your database server are correctly installed on your machine. If so, you can, for example, use the tools supplied with the database server (isql for Sybase, sqlplus for Oracle, and dbaccess for Informix) to test that you can connect to the server and execute simple SQL commands.

  2. Start your application from the command line; don't let WebObjects autostart it.

    Applications that access a database should be started from the command line or from the Project Builder launch panel. If you allow WebObjects to autostart them-depending on the server and server configuration-the resulting process may not have the permissions necessary to access the database.

  3. Make sure that the database model file is accessible to your application

    The model file should be in the Resources directory under the application's .woa directory. Taking the DodgeDemo application for example, the directory structure would look like this:

    	DodgeDemo.woa/
		DodgeDemo           (the executable file)
		Resources/DodgeDemo.eomodeld   (the model file)

  4. If you're using the ODBC adaptor on Windows NT, you should configure a "system" data source.

    Frequently, the ODBC data sources are configured as "user" data sources, which are available only to the user that created them. Autostarted WebObjects applications run with the permissions and environment of the "anonymous" user specified by the HTTP server used to start the application. If this anonymous user is not the same as the user who created the user data source, the application will not be able to use the data source.

    The best solution is to configure a "system" data source, which would be available to any process in your system. To do so:

    1. Install the most current ODBC drivers and related support software available to you.

    2. Open the ODBC Control Panel.

    3. Click the "System DSN" tab, and click the "Add" button to add a new data source.

    If your ODBC support software doesn't have this feature and you are unable to acquire a newer version of ODBC, log in as the "anonymous" user (you may have to do some configuration to get this to work) and configure a user data source that points to your database.

Table of Contents Next Section