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: Don Lindsay <email@hidden>
- Date: Sun, 18 May 2008 15:07:32 -0400
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:
@mac.com
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