Legacy Document
Important: The information in this document is obsolete and should not be used for new development.
WebObjects Framework
Radar #2260519
WOApplication.application().port() returns a nonsensical result.
Description:
If your user defaults have WOPort=-1, then WOApplication.application().port() returns -1.
Workaround:
Access the port number directly from the adaptor via:
WOApplication.application().adaptors().objectAtIndex(0).port() |
Radar #2273821
The session size numbers on the WOStats page appear to be too large.
Description:
The session size numbers are only an approximation of the actual size of the session. When an application has finished initializing, its memory size is noted. The session size that is reported is based on the memory increase since startup, and is divided by the current number of active sessions. The memory increase includes any cached data and/or data initialized after startup, skewing the size computation.
Workaround:
None.
Radar #2274039
IDs in Cookies are dropped at the front door of applications.
Description:
When "IDs in Cookies" is turned on for a WebObjects application, and you enter that application through the default request handler, cookies with old IDs are ignored in the request. In the response, new cookies for new IDs are sent back, or, in the case when there wouldn't be any new ID needed (such as in a stateless application), cookies clearing out the old IDs are sent back. This ensures that a user gets a new session when reentering a site, even if the users’s browser keeps old, non-expired cookies around. This behavior is non-customizable.
Workaround:
Use the API shouldRestoreSessionOnCleanEntry(WORequest aRequest) on the WOApplication class to control whether cookie sessions are dropped as above.
Radar #2276414
Sessions do not time out with WOAditionalAdaptors.
Description:
If you attempt to use the WOAdditionalAdaptors feature, sessions may not timeout.
Workaround:
None.
Radar #2282001
The current context and the current request aren't accessible from within a WOSession initializer.
Description:
WOSession's initializer doesn't set its context instance variable, so it isn't possible to access either the current context or the current request for use in your WOSession subclass initializer.
Workaround:
There are two ways to work around this problem. The simplest is to implement awake() on your session. At this point, the context instance variable is set. Since awake() is invoked for every request, though, you'll have to protect your code so it is executed only once in awake() (if it is initialization code, it most likely needs to happen only once). A better solution, assuming you only need the request object, is to implement createSessionForRequest() in your subclass of WOApplication:
public WOSession createSessionForRequest(WORequest aRequest) { |
Session session = (Session)super.createSessionForRequest(aRequest)// put your custom initialization that needs the request object here.; |
return session; |
Radar #2290990
Standard error and warning messages aren't localized.
Description:
When running a WebObjects application, some standard error and warning messages--such as "You have backtracked too far"--can be sent directly to the user. These messages aren't localized and can confuse a non-English user.
Workaround:
Provide your own implementation for the different handle...
Error methods in WOApplication:handlePageRestorationError for localizing the "backtracked too far" messageshandleSessionCreationError when the application is unable to create a new SessionhandleSessionRestorationError when the WOApplication is unable to find the Session
It's always a good idea to implement the above methods, providing your own logic and user interface to handle exceptional conditions.
Radar #2372492
Cookie expire header date format change.
Description:
In order to comply with RFC 2109 and the Netscape informal specification, the date format used with the cookie expire header has been changed to "%a, %d-%b-%Y, %H:%M:%S GMT". Previously %A was used rather than %a. %a formats weekdays as Mon, Tue, Wed, etc. rather than the full weekday name.
Workaround:
None
Radar #2425444
When binding a date object to a WOTextField, you must also bind a formatter.
Description:
If you bind an NSTimestamp object to a WOTextField's value attribute but do not bind either a date format string to dateFormat or a formatter object to formatter, after submission the date object will be invalid. For example, entering '10/10/20' will store an NSTimestamp with a yearOfCommonEra: 1.
Workaround:
Bind either the dateFormat or formatter attributes as well as the value attribute.
Radar #2574754
WOXMLDecoder cannot deserialize non-EO to-one relationships back from the XML document that is serialized by WOXMLCoder; the inverse relationship is missing.
Description:
If you use WOXMLCoder to serialize an EO that has a to-one relationship, WOXMLDecoder deserializes the same to-one relationship back. The same is not true for a non-EO graph that contains a to-one relationship. For example, assume that object A contains object B, and object B contains object A. The serialized object graph might look like this
<A_tag type="A" objectID="1"> <BinsideA type="B" objectID="2"> |
<AinsideB type="A" objectIDRef="1"></AinsideB> </BinsideA></A_tag> |
When you use WOXMLDecoder to deserialize the XML document, object B contains null instead of object A.
Workaround:
Use NSXMLOutputStream and NSXMLInputStream. Alternatively, you can implement post-construction initializers. For example, implement the setA method in class B and invoke it after object A has been constructed.
Radar #2818115
Unable to send E-mail in Japanese using WOMailDelivery.
Description:
WOMailDelivery was implemented using sun.net.smtp.SmtpClient, which is no long supported by Sun. This class does not support alternate encodings.
Workaround:
Subclass WOMailDelivery, and override the sendEmail method to use the JavaMail API instead of SmtpClient. Create a static method in your class to return an allocated, shared instance.
Radar #2985159
Nasty exception inexplicably thrown by WOHTMLWebObjectTag for a component that seems OK.
Description:
The declaration parser in WebObjects allows users to comment out sections of their declarations file (named ending in .wod). This commenting behavior supports both old ("/**/") and new ("//") style comments. Unfortunately, such behavior conflicts with attempts to parse bindings like: accept = "*/*";
Workaround:
Make the binding in question to a method or field of type java.lang.String that provides the value "*/*".
Radar #3005696
request.addCookie(new WOCookie()) and request.setHeaders(new NSMutableArray(new WOCookie().headerString()), "cookie") result in different Cookie value strings.
Description:
request.addCookie(new WOCookie(aName, aValue)) will result in a header of the form Cookie: aName=aValue being added to the request.
request.setHeaders(new NSMutableArray(new WOCookie(aName, aValue).headerString()), "cookie")
will result in a header of the form Cookie: aName=aValue; version=1 being added to the request.
This is because WOCookie.headerString() generates a string intended for use in a WOResponse. If you wish to use cookies on a WORequest, you must either use the addCookie() API or manually create your header value string.
Workaround:
Use request.addCookie().
Radar #3056127
You cannot upload files with a size greater than 2GB.
Description:
Because of underlying implementation details, you cannot upload files with a size greater than 2GB. Attempting to do so will result in undefined behavior.
Workaround:
None.
Last updated: 2004-12-02
  |
||
|
|
|
|
| ||
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 |