TITLE
    Porting WebObjects Applications to Unix Deployment Platforms
Article ID:
Created:
Modified:
72624
9/12/98
5/8/00

TOPIC

    This article highlights some common problems encountered moving your WebObjects 3.51 or WebObjects 4 applications from Windows NT or Mac OS X Server to HP-UX or Solaris.


DISCUSSION

    Q: How do I deploy my application, developed on Windows NT or Mac OS X Server, on a Solaris or HP-UX system?

    A: For most applications, all you have to do is install WebObjects on the appropriate platform and compile the application using the "make" utility. Be sure that the developer components are included in your WebObjects installation.

    Q: I have an EOF WebObjects application that compiles and runs correctly on Windows NT or Mac OS X Server. I've ported it to HP-UX and it compiles correctly, but when I run it I get a bus error and a core dump. What's happening here?


    A: If your application fetches many records at once, or fetches a number of very large objects, you may be running up against HP-UX's default per-process memory limits. Use the "limit" command to check your datasize and stacksize; it is possible for large EOF fetches to fill up the memory allocated for data. For more information on modifying HP-UX kernel parameters, see your HP-UX system administrator or check your HP-UX documentation.

    Q: I have an application that compiles and runs correctly on Windows NT. I've ported it to Solaris and it compiles correctly, but when I run it I get the error message:

    C annot find class or component named <MyCustomScriptedComponent> in runtime or in a loadable bundle.

    Why does this error occur on one platform but not the other?

    A: Carefully check the capitalization of your component when it is defined and called. This problem can occur when porting a WebObjects or OPENSTEP application from Solaris to Windows NT as a side effect of the fact that Solaris is case sensitive, while Windows NT is not. Thus, if a component called "MySuperGreatObject" is called in your application as "MySupergreatObject", it will compile and run correctly on Windows NT. On Solaris, however, you will get a run-time error. Since Mach and HP-UX are also case-sensitive, improper capitalization may cause run-time or link-time errors on those platforms as well.

    Q: Why won't NSTasks run under Solaris?

    A: On Solaris, the fork() command is used only in non-threaded contexts; fork1() is used for multithreaded applications. Because Apple's implementation of NSTask in WebObjects release 3.5.1 does not conform to this usage, you will not be able to use NSTasks on the Solaris platform. Instead, you will have to use fork1() and exec() to manually spawn a process.

    This code example shows how an external task might be set up to run with fork and exec for Solaris and HP-UX systems, and with NSTask for other WebObjects platforms.

    - (oneway void)startAppWithInstanceDict:(NSMutableDictionary*)instanceDict {
    // if solaris or hpux--make sure the NeXT_PDO and _svr4_ varaiables are defined
    #if ((NeXT_PDO && (__svr4__ || hpux)) || __hpux)
    {
    //Use fork and exec to launch a task manually for Solaris (and HP-UX) systems.
    // we need to build a command string that will look like:
    // DocumentPath/exec -a WODefaultAdaptor -n instanceNumber -p portNumber -d DocumentPath
    // executable path ...
    int····pid;
    int········execReturnValue;
    NSString * cmdString;
    NSEnumerator *stringEnum;
    NSString *aString;
    char *cpath, **argvp;
    int nargs, n;
    int maxfds = getdtablesize();

    NSLog(@"Executing non-Mach or non-NT code");

    //Determine whether we should use fork() (for HP-UX systems) or fork1() (for Solaris)

    #if (hpux || __hpux)
    switch ( pid = fork() )
    #else
    switch ( pid = fork1() )
    #endif
    {
    case 0:
    NSLog(@"Enter child process fork(), maxfds = %d", maxfds);

    // for ( n = 3; n < maxfds; n++)
    {
    //···· NSLog(@"Closing descriptor %d, retval = %d", n, close(n));
    //···· close(n);
    }

    cpath = [fullExePath fileSystemRepresentation];
    nargs = [cmdArray count];
    argvp = NSZoneMalloc(NULL, (2 + nargs) * sizeof (*argvp));
    argvp[0] = (char *)cpath;
    for (n=0; n < nargs; ++n)
    {
    argvp[n+1] = (char *)[[cmdArray objectAtIndex:n] cString];
    }
    argvp[n+1] = (char *)0;

    chdir([currentDir fileSystemRepresentation]);

    execReturnValue = execv(cpath, argvp);
    NSLog(@"Exec return value is %d", execReturnValue);
    exit(127);
    break;

    case -1:
    NSLog(@"*** Error: fork() returned an Error");
    break;

    default:
    NSLog(@"returning to parent process");
    // do nothing ...
    }
    }
    #else
    {

    //Use NSTask to lauch the same task on other platforms

    aTask = [[[NSTask alloc] init] autorelease];
    [aTask setCurrentDirectoryPath:currentDir];
    [aTask setLaunchPath:fullExePath];
    [aTask setArguments:cmdArray];
    [aTask launch];
    }
    #endif
    }

    Q: My custom EOF subclasses work fine on Windows NT, but when I compile on Solaris I get run-time failures.

    A: When writing a subclass of CustomObject under WebObjects 3.5.1, you should be sure that your class defines a constructor that takes the following three arguments:

    EditingContext ec, ClassDescription cd, GlobalID id

    If this constructor is missing, the application will still run on Windows NT, but will fail on Solaris systems with the WebObjects Java patch installed. The easiest way to implement this method is simply to call the superclass:

    public MyCustomEOClass (EditingContext ec, ClassDescription cd,
    GlobalID id) {
    super (ec,cd,id);
    }

    To save time, you can modify the 3.5.1 EOModeler Java templates to always create this constructor. The templates you'll need to change can be found under:

    $NEXT_ROOT/Developer/Applications/EOModeler.app/Resources/EOJavaClass.template
    $NEXT_ROOT/Developer/ProjectTypes/WebObjectsApplication.projectType/Resources/English.lproj/projectTemplate/EOJavaClass.template

    And optionally:

    $NEXT_ROOT/Developer/ProjectTypes/EOApplication.projectTypes/Resources/EOJavaClass.template

    Under WebObjects 4, the templates have been modified to correct this problem, but you may still encounter it while porting WebObjects 3.5.1 code to WebObjects 4.

    Q: When I run my app under Solaris, I get the error message:

    Program recieved signal SIGLWP, signal LWP.

    What is causing this and how can I fix it?

    A: These error messages are normal when running WebObjects apps on Solaris under GDB. They will not affect program execution, and they will only occur when running your application under GDB.


Document Information
Product Area: WebObjects
Category: WebObjects 3.5.1; WebObjects 4
Sub Category: Development
Keywords:

Copyright © 2000 Apple Computer, Inc. All rights reserved.