---

Foundation Framework

Radar #2926212

Java system properties that are defined but empty are not passed from the command line to the WebObjects application.

Description:

If you define an empty Java system property (for example,-DMyProperty) in the command line--on a terminal window, in Project Builder, or in ProjectBuilderWO--that definition is not passed to your application. This is due to ambiguity between NeXT-style property syntax (-DNeXTProperty NeXTValue) and an empty Java property definition in the command line.

Workaround:

Since WebObjects applications can read Java system properties from the application's Properties file, you can define empty properties there. The properties must be stored in a file named Properties in the application or framework's Resources directory. You can add a Properties file to the application or framework by adding it to the Resources group in Project Builder. The Properties file must be in the format specified by java.io.Properties. In the unlikely event that the property needs to be visible before themain method of the Application class, you have to use the JVMOptions hook provided in the classpath file. For example, on the Mac OS X platform, this file is located at path_to_your_app/app.woa/Contents/MacOS/MacOSClassPath.txt. Anything to the right of the equals sign on the JVMOptions line will be inserted such that the JVM itself is able to find the property.

Radar #3005482

The string produced by the toString() method for JavaFoundation collection objects (e.g., NSArray, NSDictionary) doesn't serialize the object.

Description:

According to Java convention, toString() is just used for debugging purposes, not for serialization of objects. Consequently, the string produced by toString() on JavaFoundation collection objects will not necessarily produce a valid property list.

Workaround:

The collection classes implement java.io.Serializable, which is the supported way of serializing and deserializing the collection objects.

Radar #3063536

WOXMLDecoder will call the getter methods, if they are present, of your class during decoding. And the setter methods will not get called if the property's value has not changed.

Description:

As part of a bug fix and an optimization, WOXMLDecoder (with or without a mapping file) will now call NSValidation.Utility.validateTakeValueForKeyPath() instead of NSKeyValueCodingAdditions.Utility.takeValueForKeyPath().There are two side effects of this change:

1. validateTakeValueForKeyPath() will end up calling the getter method for each property to be set. This is to compare if the value has changed. Thus if you have codes in your getter method that don't simply return the value, you might have unexpected results.

2. A consequence of (1) is that the setter method might not be called if the property's value has not changed.

Workaround:

Scan the getter methods for potential unexpected results. If the setter methods contain initialization codes, move them out to a separate method and call that method after the object has been decoded.

---