This document answers some common questions about the 4.0.1 release of Apple's WebObjects application server development system.

Q: What is WebObjects 4.0.1?

A: WebObjects 4.0.1 was released in conjunction with Apple's MacOS X Server operating system. Its most important feature is support for the MacOS X Server platform. However, the release also includes several other enhancements, including more examples, tutorials, and documentation; enhancements to WOInfoCenter; and several high priority bug fixes. See below for details on specific changes made in this release.

Q: How do I get WebObjects 4.0.1?

A: If you're a licensed user of WebObjects 4 on Windows NT, Solaris, or HP-UX, Apple will mail you a CD of WebObjects 4.0.1 automatically. If you received WebObjects 4 as part of the MacOS X Server distribution, or if you received your copy of WebObjects 4 after mid-April, 1999, you already have WebObjects 4.0.1. If you have questions about your status, please contact your Apple sales representative for more information.

Q: What version do I currently have installed?

A: The WebObjects CD has a version number printed on the right-hand side, underneath the platform identifier. It will say either "WebObjects 4.0" or "WebObjects 4.0.1."

Q: I've received my copy of WebObjects 4.0.1, and I already had WebObjects 4.0 installed. Do I need to uninstall my old WebObjects or can I just install WebObject 4.0.1 over it?

A: You must completely uninstall WebObjects 4.0 before installing WebObjects 4.0.1. See the WOInfoCenter for instructions on uninstalling the software.

Q: What changed in WebObjects between the 4.0 and 4.0.1 releases?

A: WebObjects 4.0.1 supports MacOS X Server and Solaris 2.7. There were many changes and corrections made to the tutorials, examples, and documentation, including enhancements to WOInfoCenter itself. A new application, the WebObjectsLicenseKeyUpgrader, was added to make it easier for customers to upgrade their deployment licenses after installation. In addition, the following specific bugs were corrected for this release:

WODefaultAdaptor hangs on stale socket
Apple reference # 2281185

ISSUE:
The WODefaultAdaptor could not recover from a situation where the socket it was using went bad.

RESOLUTION:
The WODefaultAdaptor now recognizes when there is an issue and tries to recreate the socket.

EOPopUpAssociation passes duplicate items to AppKit
Apple reference # 2289602

ISSUE:
If multiple identical items were passed from an EOPopUpAssociation to an AppKit NSPopUpButton, the AppKit object would raise an exception.

RESOLUTION:
EOPopUpAssociation now uniques its contents before passing them to the AppKit.

ODBC date values cause crash
Apple reference # 2289803

ISSUE:
Generating EOF dates from an ODBC database's timestamps would sometimes cause an "invalid date format" error. This was due to an error in the code which rounded ODBC time values from nanoseconds to milliseconds.

RESOLUTION:
EOF now truncates timestamp values instead of rounding them. Optimistic locking and other functions which require timestamp comparison will no longer cause this exception.

Resources missing from preindexed frameworks
Apple reference # 2292280

ISSUE:
If a framework was preindexed, WebObjects Builder would not load any of the project's resources.

RESOLUTION:
WebObjects Builder now recognizes the resources of preindexed projects correctly.

EOProject parser does not recogize some method names
Apple reference # 2292470

ISSUE:
If EOProject's parser encountered a method named just "get" or "set" while checking for accessor methods, an exception would be raised.

RESOLUTION:
The parser now checks for and handles this condition correctly.

EOEditingContext archiving issues
Apple reference # 2297455

ISSUE:
EOEditingContext's encodeWithCoder: and initWithCoder: methods were not thread safe. In addition, under certain conditions, the archive methods could overwrite meaningful changes and result in lost data. These methods would also fail if an object was unarchived from a data store other than the default data store, or if the object being edited was the entry point to the archive.

RESOLUTION:
EOEditingContext's archiving methods have been rewritten to avoid these issues.

EOEditingContext saveChanges() exceptions not propogated to Java
Apple reference # 2297457

ISSUE:
Exceptions raised within EOEditingContext's saveChanges() method would not propogate to Java unless they were caused by a validation failure.

RESOLUTION:
These exceptions are now propogated to Java correctly.

Application inactivity timeout is broken
Apple reference # 2297505

ISSUE:
If an inactivity timeout was set for a WebObjects application, the app would crash when the timeout expired.

RESOLUTION:
WebObjects applications will now exit cleanly after the timeout is reached.

Memory leak in WODisplayGroup
Apple reference # 2298170

ISSUE:
WODisplayGroup's -initWithCoder: method leaked a small amount of memory each time it was called.

RESOLUTION:
The leak in this method has been eliminated.

Exception handlers may message freed objects
Apple reference # 2298174

ISSUE:
If an exception was raised and caught by a handler which unlocked an editing context, the exception could be freed before it was reraised. This would cause a fatal error rather than a catchable exception.

RESOLUTION:
EOF's internal exception handlers have been modified to prevent this behavior.

Undo manager not thread safe
Apple reference # 2298337

ISSUE:
When the NSUndoManager was handled at the endOfEvent notification, while it's editing context is unlocked, it was possible for a new request for the same session to come in, causing the same instance of the undoManager to be accessed by two threads at once. This would cause occasional crashes in some high-volume applications.

RESOLUTION:
The endOfEvent notification is now posted before the editing context is unlocked, and these crashes no longer occur.

Sybase adaptor may generate duplicate primary keys for multiple application instances
Apple reference # 2299035
ISSUE:
The Sybase adaptor uses a stored procedure called "eo_pk_for_table" to generate primary key values. Because this stored procedure does not run in a transaction, if two application instances request a primary key simultaneously, they could be assigned the same primary key.

RESOLUTION:
The "eo_pk_for_table" stored procedure now runs in a transaction. Duplicate primary keys will no longer be generated.

Adaptor tries to reconnect to dead instances
Apple reference # 2300000

ISSUE:
The WebObjects adaptor would re-read the WebObjects configuration file even when the compiled adaptor parameters told it not to. A a result, dead instances would come back into the list too often. If adaptor logging were turned on, and an application instance were killed, you could see the adaptor repeatedly trying to re-connect to the app instance, despite its being marked dead.

RESOLUTION:
The WebObjects adaptor now re-reads the configuration file in accordance with the compiled adaptor parameters.

WOLongResponsePage issues in Java apps
Apple reference # 2300113

ISSUE:
Because of a bug in NSJavaVirtualMachine, Java-based applications were not able to use the WOLongResponsePage.

RESOLUTION:
This issue no longer occurs in this release.

Can't open older eomodels with current tools
Apple reference # 2300129

ISSUE:
WebObjects would fail to read archived eomodel files which had been generated by older WebObjects versions.

RESOLUTION:
WebObjects now reads these files correctly.

Cross-model relationships crash EOModeler
Apple reference # 2300382

ISSUE:
EOModeler would crash when the user attempted to close a model with relationships to other models.

RESOLUTION:
EOModeler now handles these relationships correctly.

OBLite Adaptor may contain incorrect typeInfo and modelInfo information
Apple reference # 2301085

ISSUE:
In some cases, the typeInfo and modelInfo information of an OBLite connection dictionary would be corrupted, crashing a customer's application or preventing database access.

RESOLUTION:
Since the typeInfo and modelInfo are the same for every OBLite database, the values have now been hard-coded into the adaptor and can no longer be corrupted.

NT Sybase adaptor compiled with older client libraries
Apple reference # 2301732

ISSUE:
On Windows NT, the Sybase Adaptor shipped with an older version of the Sybase client libraries, which were not certified by Sybase for Year 2000 compliance.

RESOLUTION:
The Sybase client libraries that ship with WebObjects 4.0.1 are an updated version that Sybase has certified as Year 2000 compliant.

Crash when passing null java.math.BigDecimal
Apple reference # 2307624

ISSUE:
If a null value was passed to a wrapped object which was expecting a java.math.BigDecimal, it would crash the application.

RESOLUTION:
WebObjects now checks for null values and handles them correctly.

WebObjects header files conflict with C++ compilation
Apple reference # 2309963

ISSUE:
Some C++ reserved words were used in the WebObjects headers files. This caused serious issues with the compilation of C++ code for WebObjects applications.

RESOLUTION:
Customers can now use hybrid WebObjects Objective C objects in their applications.

Using enumerations with Java causes deadlocks
Apple reference # 2283190

ISSUE:
Using enumerations on Foundation collections from Java would cause deadlocks during garbage collection. This would happen because the enumerator object was being released too early.

RESOLUTION:
The enumerator object is now released at the proper time, and the error no longer occurs.

NSNumber can't accept some valid values
Apple reference # 2211791

ISSUE:
The numberWithLongLong: and numberWithUnsignedLongLong: constructor methods of NSNumber would fail for very large numbers.

RESOLUTION:
All of NSNumber's constructor methods now work correctly for appropriate values.

Can't compile with Foundation and -ansi flag
Apple reference # 2228578

ISSUE:
The gcc compiler would not compile a class which imported the Foundation framework when the -ansi flag was set. This was due to an omission in one of the framework header files.

RESOLUTION:
The relevant header file has been fixed and these classes now compile correctly.

Date constructors give wrong date for nil input
Apple reference # 2256550

ISSUE:
If the locale argument to the various date classes' dateWithNaturalLanguageString:locale : method was nil, incorrect results would be returned because the classes were not correctly determining the language selected by the system.

RESOLUTION:
The date classes now determine the system default locale and return a correct date value.

Files which import NSString.h causes compiler warnings on HP-UX
Apple reference # 2258616

ISSUE:
Because of a naming conflict between NSString.h and NSObjCRuntime.h, compiling any file which imported NSString.h would cause many compiler warnings on HP-UX. This would not affect compilation, but it was annoying and made it difficult to find real compiler errors.

RESOLUTION:
The conflict has been resolved and these errors no longer occur.

NSDateFormatter interprets year "00" as "Current Year"
Apple reference # 2278053

ISSUE:
NSCalendarDate would interpret year "0" or "00" as "current year", rather than "2000", which was inconsistent with the interpretation of two-digit years in UNIX and not Year 2000 compliant.

RESOLUTION:
NSCalendarDate now interprets "0" or "00" year values as "2000"

Bundle class loader loads all classes in main component
Apple reference # 2280719

ISSUE:
The Java VM would become confused when classes in the main bundle are loaded by two different class loaders. This would happen because the Java warmup code in Foundation forced the bundle class loader to load all classes in the main bundle, despite having passed the main bundle's Java resources directory in the class path to the VM. The result would be spurious security and class cast exceptions.

RESOLUTION:
The bundle no longer loads all of these classes, and these errors no longer occur.

Java object notifications not thread safe
Apple reference # 2287349

ISSUE:
Due to timing issues, in multithreaded Java applications notifications would sometimes be sent to freed objects.

RESOLUTION:
The NotificationCenter now uses a locking system to provide full multithreading support.

dateWithYear doesn't accept nil time zone
Apple reference # 2258428

ISSUE:
The NSCalendarDate constructor dateWithYear:month:day:hour:minute:second:timeZone: would not accept a nil value for the time zone. If a nil time zone was passed, the constructor would return nil.

RESOLUTION:
A nil value is now interpreted as the current time zone.

NSDate methods calculate incorrect dates across DST boundary
Apple reference # 2281625

ISSUE:
The NSCalendarDate methods dateByAddingYears:months:days:hours:minutes:seconds: and years:months:days:hours:minutes:seconds:sinceDate: would not handle time zone transitions correctly. Thus, the number of minutes between two dates separated by a daylight savings time boundary was not calculated correctly.

RESOLUTION:
Daylight savings time transitions are now calculated correctly.

Redirected HTTP URL headers are case sensitive
Apple reference # 2287408

ISSUE:
NSURL would not recognize redirections if the HTTP headers were not capitalized correctly.

RESOLUTION:
NSURL now handles the case where redirection headers are improperly capitalized.