Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#9393 closed defect (fixed)

Custom build fails in jslib/i18nUtil.flattenLayerFileBundles()

Reported by: William Chapman Owned by: James Burke
Priority: high Milestone: 1.4
Component: BuildTools Version: 1.3.0
Keywords: i18n, custom build, Cc: Richard Backhouse, Adam Peller
Blocked By: Blocking:


Custom build generates error:
"js: uncaught JavaScript? runtime exception: TypeError?: Invalid iterator value"

dojo: 1.3.0-src

os: ubuntu 9.04

rhino: 1.7R1-2

browser: n/a

Please see forum post for additional details, including build profile.

Files attached (per jburke's suggestions):

(1) gzip of "com.mp3srv.nls" directory

(2) screenshot of "com.mp3srv" directory tree;

Wm. J. Chapman
[email protected]

Attachments (2)

nls.tar.gz (10.0 KB) - added by William Chapman 13 years ago.
gzip of "com.mp3srv.nls" directory
Screenshot-com.mp3srv-nautilus_tree.png (178.4 KB) - added by William Chapman 13 years ago.
screenshot of "com.mp3srv" directory tree (nautilus)

Download all attachments as: .zip

Change History (9)

Changed 13 years ago by William Chapman

Attachment: nls.tar.gz added

gzip of "com.mp3srv.nls" directory

Changed 13 years ago by William Chapman

screenshot of "com.mp3srv" directory tree (nautilus)

comment:1 Changed 13 years ago by James Burke

Cc: Adam Peller added

I can reproduce the issue. Apparently the issue is because of the "com" namespace that is used for this module. My guess is that "com" in Java-land is important in some way.

If I just renamed the top-level directory to "com2" and changed my sample smc.js file to use "com2" references (as well as the build profile mentioned in the forum thread) it works.

I am not sure what to do about this. Seems like we should allow "com" for a JS namespace.

peller, do you or any of your java friends have an idea?

comment:2 Changed 13 years ago by Adam Peller

Cc: Richard Backhouse added
Component: GeneralBuildTools
Owner: changed from anonymous to James Burke

I used to be a Java person, but I've conveniently forgotten most of that stuff :) iirc, this is a remnant of LiveConnect? (JS<>Java communications) I think the old Netscape 4 browser used to let you call Java code using java.*, sun.*, perhaps with a Java plugin today's browsers still allow this directly through the global object? Rhino has a special "Packages" property on global you're supposed to use to access the root Java namespace, but it also provides aliases for common first-level namespaces java, com, net, and org, at least, and the Packages keyword is optional. Each of these return "JavaPackage?" objects which introspect into Java packages, but you cannot actually iterate through them in js.

Now if I do an assignment to replace 'com' or 'delete com', it then acts like a normal JS object. The loader probably checks for the 'com' root namespace, sees that it is non-null, and tries to use it as if it were a JS object. Maybe it makes sense for us to start out by deleting these things in Rhino at the top of our script?

delete com;
delete net;
delete org;

Technically, 'java' is another one of these conflicts. If we wanted to allow 'java' as a root JS namespace, we could delete it as well, but we'd need to make sure all of our actual Java code references use a "Packages." prefix.

comment:3 Changed 13 years ago by William Chapman

William Chapman added the following note regarding the "com" namespace:

David Flannigan, author of O'Reilly's JavaScript? The Definitive Guide, argues for using JavaScript? namespaces based on domain names to keep the window object uncluttered. This plays in to dojo.provide() and dojo.require().
See referenced book, 5th Edition, section 10.1, page 186 for an example.

So, using namespaces like, e.g., "com.mydomain.myapplication" might be important to support.

comment:4 Changed 13 years ago by William Chapman

William Chapman added the following comment about util/buildscrxipts/jslib/i18nUtil.flattenLayerFileBundles():

I've noticed the following undesirable (to me) behavior in this method (for which I needed to rework my code to get as far as I did) that might need some work:

(1) This line of code (line 62) finds the dojo.requireLocalization() calls:

	var requireStatements = fileContents.match(/dojo\.requireLocalization\(.*\)\;/g);

But this code is not sensitive to comments, so it includes commented out calls.
Perhaps comments should be stripped before processing.

(2) This code block (lines 55-60) gets tripped up if the bundlename argument of the dojo.requireLocalization() call contains anything but a literal string:

	var drl = dojo.requireLocalization;
	dojo.requireLocalization = function(modulename, bundlename, locale){
		drl(modulename, bundlename, locale);
	//TODO: avoid dups?
		djLoadedBundles.push({modulename: modulename, module: eval(modulename), bundlename: bundlename});

So, as it stands, developers need to know - that if they intend to use the build utility - to avoid writing something like this:

    lang.requireLocales = function (locale) {
        dojo.forEach(["bundle1", "bundle2", "bundle3"], function (bundle) {
            dojo.requireLocalization("moduleName", bundle, null);

comment:5 Changed 13 years ago by William Chapman

For what it's worth, rbackhouse's suggestion to add this line of code

    delete com; // added: wjc 11 June 2009

to the beginning of allowed my profile to build to completion (after fixing an unrelated problem in one of the bundles - still in the attached gzip - plus other profile issues).

Now I'm struggling with actually getting the bundle items via dojo.i18n.getLocalization(). It seems that my fully functional development code is not working in build trim. All the dojo.requireLocalization() calls have been deleted by the build process (as expected), and the dojo.i18n._preloadLocalization() call is executing successfully upon loading the application (the get() is successful and the object shows up in the dojo.nls namespace). However, dojo.i18n.requireLocalization() calls don't work, throwing Error: bundle not found exception in Firebug. ???

I'm going to post this to the Dojo Core Support forum, hoping for some insight. Thanks for your effort on this issue. I will continue to track, and be available to help if I'm able.

comment:6 Changed 12 years ago by James Burke

Resolution: fixed
Status: newclosed

(In [20402]) Fixes #9393, allow option to remove the com, org and net namespaces that rhino creates by default, but have the option be false by default -- it could cause havoc in a rhino-based server side system that uses the build code.

comment:7 Changed 12 years ago by bill

Milestone: tbd1.4
Note: See TracTickets for help on using tickets.