Re: Workaround for WO 5.4 "WebAssistant: You backtracked too far"
Re: Workaround for WO 5.4 "WebAssistant: You backtracked too far"
- Subject: Re: Workaround for WO 5.4 "WebAssistant: You backtracked too far"
- From: David Elliott <email@hidden>
- Date: Sun, 18 May 2008 22:41:03 -0400
Hi Don,
I just filed this as rdar://5944941. Probably should've down that
earlier but it slipped my mind.
I have a workaround for it too which is to simply instantiate
D2W._Observer and add it to the notification center. Take care to
keep a reference to the variable. That is, assign it to a private
variable in your Application class. The decompiled code for the
_enableTracking() method is basically what you need except that you'll
be implementing it as a method in your Application class so you'll
have to use D2W.factory() as the object to instantiate the
D2W._Observer inner-class from.
The downside is that if you have this workaround in place and Apple
fixes the bug then the requestWasHandled method will wind up getting
called twice. So if you employ this workaround as a short-term fix,
be sure to remove it later.
-Dave
On May 18, 2008, at 3:07 PM, Don Lindsay wrote:
Hello;
I am experiencing this bug as well, if it is a bug. Is this caused
by a bug or by misconfiguration on my part?
don
On Jan 18, 2008, at 10:37 PM, David Elliott wrote:
Hi,
I am just starting to play with WO again after having worked on
some other stuff and have come across what I believe to be a bug in
the D2W class. I tried googling the "WebAssistant: You backtracked
too far" error message with no positive results and finally decided
to track it down myself.
What I came up with appears to be a weak reference problem with the
D2W._Observer instance used to observe the
WORequestHandlerDidHandleRequestNotification. For other
notifications including that same notification as used to call the
willCheckRules method, the D2W singleton itself is registered with
NSNotificationCenter.
The relevant (decompiled) code is as follows:
class D2W {
...
static {
...
NSNotificationCenter.defaultCenter().addObserver(factory(),
new NSSelector("willCheckRules", _NotificationArray),
"WORequestHandlerDidHandleRequestNotification", null);
}
...
};
But the requestWasHandled method is registered indirectly (why!?)
through an inner class:
class D2W {
...
public class _Observer
{
public void requestWasHandled(NSNotification n)
{
Object object = n.object();
if(object instanceof WOContext)
D2W.factory().requestWasHandled((WOContext)object);
}
final D2W this$0;
public _Observer()
{
this$0 = D2W.this;
super();
}
}
...
private void _enableTracking()
{
if(!_trackingEnabled)
{
Object trackingObserver = new _Observer();
NSNotificationCenter.defaultCenter().addObserver(trackingObserver,
new NSSelector("requestWasHandled", new Class[] {
com/webobjects/foundation/NSNotification
}), "WORequestHandlerDidHandleRequestNotification", null);
_trackingEnabled = true;
}
}
...
};
By dropping into the Eclipse debugger on NSNotificationCenter and
stepping through until it finally fills in its targets stack
variable I was able to inspect the contents and determine that the
target object which should be an instance of D2W._Observer is
instead null. I suspect that the NSNotificationCenter must
therefore only weakly reference its targets such that it does not
keep them from getting garbage collected. I'm reasonably sure
that's an intentional design and is certainly a good thing in light
of the recent story about the university students competing in the
DARPA challenge who were oh so surprised when they found a "memory
leak" in their .NET app because their notification center was
referencing its targets.
I am able to fix this by adding a D2W._Observer ivar to my
Application class and basically using the above code from the
_enableTracking() method except setting the ivar to the new
_Observer instance rather than using a stack variable. With that
code in place I am once again able to use the Customize button from
my D2W app.
Of course I still haven't gotten WOLips to tell WebAssistant to
save the file to the source code directory (it saves to the bundled
copy which gets overwritten on the next build) but it's progress
nonetheless.
Has anyone else seen this bug or reported it? Should I go ahead
and do that? It seems to me that the simple fix is to just add a
requestWasHandled(NSNotification) overload directly to D2W rather
than using an inner class.
-Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden