Hey all,
I'm in over my head again. But at least the "good" news is that I think I'm
finally inching my way toward the deep end of the pool...
We're suddenly running into the WOBrowser
"java.lang.UnsupportedOperationException: addAll is not a supported operation
in com.webobjects.foundation.NSArray" problem as others have run into.
We have a WOComponent that has three WOBrowsers on it. One selects one or more
"Categories" from all possibilities. The other two manage what related objects
are related to the selected Categories. One with Available Objects, and one
with Assigned Objects. Basically, with 3 WOBrowsers we are managing a
Many-to-Many relationship.
Now, we can easily avoid the error by just making sure that the "selections"
bindings of the WOBrowsers are not null. Initializing them with
NSArray.emptyArray() works just fine.
There are two odd things:
1) We just started running into this problem and this code has been running
unchanged for years, and Wonder's last change was 16+ months ago
2) There are three WOBrowsers on the Page (2 in one component, 1 in a parent
component) and only ONE of the WOBrowsers is causing this error.
I believe there is a bug in WO's or WOnder's handling of WOBrowser, but maybe
(probably) I'm just not fully understanding the implications of multiple
WOBrowsers in one Page and the Request-Response loop.
526 if(_selections != null && _selections.isValueSettable()) {
526 try {
527 Class resultClass = listClassInContext(context);
528 Object result = resultClass.newInstance();
529 if(result instanceof NSMutableArray) {
530 ((NSMutableArray)result).addObjects(selections.toArray());
531 } else {
532 if(result instanceof List) {
533 ((List)result).addAll(selections);
534 }
535 }
536 _selections.setValue(result, context.component());
537 } catch(Exception exception) {
If I add the following two lines:
531 + } else if (result instanceof NSArray) {
532 + result = new NSArray(selections.toArray());
Or surround lines 529 - 535 with the following if clause:
529 + if (selections != null && !selections.isEmpty()) {
...
537 + }
Then everything works just fine, even if the selections bindings end up null.
That's all very special, but it just covers up the real problem by intercepting
the bad data before it can cause an error. They don't fix what is causing the
bad data in the first place.
It appears that for some reason line 527's call to
EOAssociation#listClassInContext(context) for just ONE of the three WOBrowsers
returns an instance of NSArray instead of an NSMutableArray. The one that gets
an NSArray Class is the third WOBrowser on the page, but possibly more
significantly it's the second with a null "selections" binding.
What I don't get is why would EOAssociation#listClassInContext(context) return
different Class objects (NSMutableArray for the first, NSArray for the second)
even when both WOBrowser "selections" bindings are null?
Does anybody have any ideas?
(Clarification for Chuck: I mean ideas that don't directly or indirectly
involve bourbon and/or hookers)
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
