Workaround for WO 5.4 "WebAssistant: You backtracked too far"
Workaround for WO 5.4 "WebAssistant: You backtracked too far"
- Subject: Workaround for WO 5.4 "WebAssistant: You backtracked too far"
- From: David Elliott <email@hidden>
- Date: Fri, 18 Jan 2008 22:37:26 -0500
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