Advanced Search

Log In | Not a Member?

Contact ADC

< Previous PageNext Page > Hide TOC

WebObjects

Radar #2806377

Fatal exception when programmatically creating an EOEditingContext in a Cocoa/EOF java class.

Description:

In some circumstances, creating an EOEditingContext programmatically in a Cocoa/EOF java class throws a NullPointerException. Specifically when the editing context is created very early in the application startup phase, such as in the NSApplication delegate's constructor or applicationDidFinishLaunching delegate method AND there is no EOEditingContext instantiated in the related Nib file.

Workaround:

Leave an EOEditingContext instance in the application's Nib files (One is added to the Nib for you by the WOAssistant).ORInvoke com.webobjects.eointerface.cocoa.EOCocoaUtilities.registerCocoaSet() before programmatically creating an EOEditingContext

Radar #2907225

JavaClient applications using WebStart(tm) against a Windows 2000 Professional server may fail to launch with a Download Error.

Description:

If the server is running Windows 2000 Professional and IIS 5.x, JavaClient applications may fail to launch through WebStart(tm). WebStart will return a Download Error - “Unable to load resource.”

This is because IIS running on Windows 2000 Professional is limited to 10 concurrent requests.

Workaround:

Upgrade to Windows 2000 Server, or try loading the JavaClient application again.

Radar #2948731

Deadlock with EOSharedEditingContext.

Description:

A race condition can cause an application that uses EOSharedEditingContext to deadlock. This deadlock can occur when the shared editing context receives a change notification concurrent with access from another thread. The deadlock can be identified by thread(s) being blocked with the following appearing in the backtrace:

ava.lang.Object.wait (Native Method)

java.lang.Object.wait (Object.java:420)

com.webobjects.foundation.NSMultiReaderLock$ConditionLock.await

(NSMultiReaderLock.java:503)

Workaround:

For more details, see What’s New in WebObjects 5.2 and API Changes from 5.1.

Radar #3035679

Top-level components can't be stateless.

Description:

To make a component stateless, one must override the component's isStateless method so that it returns true. However, overriding this method on a top-level component (i.e. Main) won't have any effect on his stateless status. In fact, a new top-level component will be replicated as needed instead of being shared between sessions.The stateless status was designed to be used for nested subcomponents because it is there where the advantage of sharing one instance has more relevance.

Workaround:

Not applicable.

< Previous PageNext Page > Hide TOC

Did this document help you? Yes: Tell us what works for you. It’s good, but: Report typos, inaccuracies, and so forth. It wasn’t helpful: Tell us what would have helped.

	Get information on Apple products. Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. | Terms of use | Privacy Notice