It's all about the answers!

Ask a question

debug=true and loading things in dojo.require


Muhtar Akbulut (9111) | asked Sep 04 '07, 11:55 a.m.
JAZZ DEVELOPER
We noticed some of our code that does not work due to "Could not locate widget implementation for XXXX in dojo.widget registered to namespace dojo" starts to work when we use debug=true in the URI.

Code that has the above issue uses dojo.require() for all the widgets it needs. For some cases, if I move dojo.require for the missing widget into code that is loaded earlier (e.g. Workbench.js), the code starts to work without debug=true.

Any ideas?

12 answers



permanent link
Richard Backhouse (6661) | answered Sep 17 '07, 9:13 a.m.
JAZZ DEVELOPER
Adam,

Thanks for the headsup on this. Definitely has some great new features.

A word of warning to anyone who tries this though. I would suggest
disabling firebug for jazz.net as I have found that it makes the browser
unresponsive for quite some time.

Richard

apeller wrote:
John Barton at IBM Almaden has been working on a patch for Firebug so
it can debug code in evals. You can find the experimental code at
http://fireclipse.xucia.com/ FWIW, other debuggers like MSVC and
Drosera can already handle this, to some extent, so another answer is
to try it in IE.

All that said, I still find that debuggers, particularly Firebug, tend
to miss exceptions from time to time.

permanent link
Adam Peller (6) | answered Sep 16 '07, 9:21 p.m.
John Barton at IBM Almaden has been working on a patch for Firebug so it can debug code in evals. You can find the experimental code at http://fireclipse.xucia.com/ FWIW, other debuggers like MSVC and Drosera can already handle this, to some extent, so another answer is to try it in IE.

All that said, I still find that debuggers, particularly Firebug, tend to miss exceptions from time to time.

permanent link
Muhtar Akbulut (9111) | answered Sep 16 '07, 7:29 a.m.
JAZZ DEVELOPER
If the code is in an eval() block, the code stops at a break point in that case, but you cannot see the matching source code. There is a note on this in Firebug, and it is a known issue. Because optimizer-related and "debug=false only" cases often end up in an eval block, debugging becomes challenging. Guessing the offset in actual source, and looking at the stack helps to guess what is running, but having the correct source and line would help. Do you know a way for that?

permanent link
Bill Higgins (24611) | answered Sep 15 '07, 5:51 a.m.
Another trick I've adopted recently is that when I'm having bizarre problems, I run in debug mode and set Firebug to break on all errors (an option in the 'Script' view). This makes sure that even if code is swallowing an exception (a common cause of mysterious problems), you can still find it.

Just remember to turn off 'break on all exceptions' afterwards or you'll soon discover how many bugs are out on the web. :-)

permanent link
Richard Backhouse (6661) | answered Sep 14 '07, 10:20 a.m.
JAZZ DEVELOPER
Here is an update on what the issues were. It turns out that the code
was using two Dojo widgets that were badly written.

One module was written in such a way that it would not be able to be
built using the Dojo build system. The Jazz WebUI optimizer is using
part of the build system for dependency analysis.

The other module had invalid syntax. While it loaded ok when directly
referenced via script tags or loaded in with the main dojo.js module it
failed to load when interpreted via an eval statement. It seems that
eval has stricter syntax requirements.

As far as a process for troubleshooting. I think this one is a special
case as the issues were in fact with Dojo code itself. Certainly turning
on debug via the ?debug=true parameter is the first step.

Richard

Christophe Elek wrote:
Richard Backhouse <backhous@us.ibm.com> wrote in news:fcbf8g$l1f$1
@localhost.localdomain:

Christophe,

Just as an FYI. I have contacted Muhtar directly to work on getting his
issue resolved. I will post an update when we have figured out what is
going on.

Richard

Richard :) Great :)
Could you also let us know the proces you followed to troubleshoot, so we
can use the sam in support ? :) thx :)

permanent link
Richard Backhouse (6661) | answered Sep 13 '07, 9:51 a.m.
JAZZ DEVELOPER
Christophe,

Just as an FYI. I have contacted Muhtar directly to work on getting his
issue resolved. I will post an update when we have figured out what is
going on.

Richard

Christophe Elek wrote:
makbulut@us.ibm-dot-com.no-spam.invalid (makbulut) wrote in news:fc9fpc$pqa
$1@localhost.localdomain:

I wonder if this may be related to the Jazz web optimizer, because all
our problems go away when we turn off webui.optimized. I believe
debug=true stops optimization even if webui.optimized = true.

Hello, I do not have the answer but I just want to tell you we are really
interested in this issue.
So I will closely follow this thread and work with Bill.

The reason is that we do not have *yet :)* a great way to debug js issues
and we know thay may occur and will be really time consuming.

Don't despair, it may take us a while to figure ths one out, but I promise
you we really care and want to work with you so we can fix this problem,
and then learn the best practices so we can improve JS troubleshooting :)

Just my 2cents.. if you have recommendations, let us now :)

permanent link
Christophe Elek (2.9k13021) | answered Sep 13 '07, 7:38 a.m.
JAZZ DEVELOPER
Richard Backhouse <backhous@us.ibm.com> wrote in news:fcbf8g$l1f$1
@localhost.localdomain:

Christophe,

Just as an FYI. I have contacted Muhtar directly to work on getting his
issue resolved. I will post an update when we have figured out what is
going on.

Richard

Richard :) Great :)
Could you also let us know the proces you followed to troubleshoot, so we
can use the sam in support ? :) thx :)

--
Christophe Elek
Serviceability Architect
IBM Software Group - Rational

permanent link
Christophe Elek (2.9k13021) | answered Sep 13 '07, 4:11 a.m.
JAZZ DEVELOPER
makbulut@us.ibm-dot-com.no-spam.invalid (makbulut) wrote in news:fc9fpc$pqa
$1@localhost.localdomain:

I wonder if this may be related to the Jazz web optimizer, because all
our problems go away when we turn off webui.optimized. I believe
debug=true stops optimization even if webui.optimized = true.

Hello, I do not have the answer but I just want to tell you we are really
interested in this issue.
So I will closely follow this thread and work with Bill.

The reason is that we do not have *yet :)* a great way to debug js issues
and we know thay may occur and will be really time consuming.

Don't despair, it may take us a while to figure ths one out, but I promise
you we really care and want to work with you so we can fix this problem,
and then learn the best practices so we can improve JS troubleshooting :)

Just my 2cents.. if you have recommendations, let us now :)

--
Christophe Elek
Serviceability Architect
IBM Software Group - Rational

permanent link
Muhtar Akbulut (9111) | answered Sep 12 '07, 3:44 p.m.
JAZZ DEVELOPER
That did not help, but turns out there is an exception that gets lost. I cannot tell exactly where it happens, because it happens during an eval (and the FF debugger gets confused debugging eval statements), but the error is the following:
TypeError:setting a property that has only a getter

I wonder if this may be related to the Jazz web optimizer, because all our problems go away when we turn off webui.optimized. I believe debug=true stops optimization even if webui.optimized = true.

permanent link
Bill Higgins (24611) | answered Sep 05 '07, 10:11 a.m.
Not having a lot of information, based on the symptoms you described, my *guess* is that somewhere during code loading, an exception is being thrown and swallowed. This could prevent some of your widgets from actually getting registered even though the require statements are correct.

My *first guess* is that there's a failure happening during widget definition, so I'd suggest doing the following: override dojo.widget.defineWidget and surround it with a try/catch block to catch the exception.

Somewhere high up in the code stack, like Workbench.js, do something like this:

dojo.widget.__oldDefineWidget = dojo.widget.defineWidget;
dojo.widget.defineWidget = function(widgetClass, renderer, superclasses, init, props){
try {
dojo.widget.__oldDefineWidget(widgetClass, renderer, superclasses, init, props);
} catch(e) {
alert(e.name + ": " + e.message + "\nFile: " +
e.fileName + " (Line: " + e.lineNumber +
")\n\n" + "Stack: " + "\n" + e.stack);
}
}

Note that only Firefox has nice exception properties; IE only has e.message and it's the same message you get in the IE trim.

If this doesn't work, then you'll have to do a brute force approach of inserting alert statements into the code that's failing and tracing back to where your alerts stop showing up.

Please let us know how this goes and what the problem is so that we can figure out how we can provide more feedback on these sorts of problems.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.