Blocking bug in SmartGWT.mobile DataSource loader

[chrylis]

I've been getting odd exceptions from GWT dev mode indicating invalid JavaScript syntax only when I try to load certain of my DataSources (using the SmartGWT server-side framework and the DataSourceLoader servlet). I've traced the problem to the specific bug, and here's what's happening:

Our DataSource has an auto-derived schema and then a few field-specific overrides. This causes the DataSourceLoader servlet to generate a nested DataSource specification that looks like this (beginning only):

if (window.isc == undefined || window.isc.DataSource == undefined){  alert("Can't load DataSources - SmartClient runtime not loaded");}isc.DataSource.create({
    allowAdvancedCriteria:false,
    "fmt:bundle":{
        basename:"ds"
    },
    fmt:"urn:jsptld:http://java.sun.com/jsp/jstl/fmt.tld",
    [b]inheritsFrom:isc.DataSource.create[/b]({
        allowAdvancedCriteria:true,
        dropExtraFields:true,
        ID:"ds_customer_inheritsFrom",
        generatedBy:"SNAPSHOT_v8.3d_2012-07-25/Pro Deployment 2012-07-25",
        fields:[
            {
                name:"version",
                length:255,
                type:"integer",
                required:true,
                canEdit:true
            },

The SmartGWT.mobile implementation of DataSource supports loading multiple DataSources in one batch by the (undocumented and somewhat counterintuitive) means of calling "load" with a comma-separated list of DataSource IDs. It then takes the entire response body and, instead of directly executing it like SmartClient does, it tries to partially parse the configuration. However, the initial step in the parsing makes an invalid assumption:

[b]DataSource.java:1676[/b] String[] configs = creationText.split("isc.DataSource.create");

As you can see in the DSL-generated response, this command splits the single DataSource into what SmartGWT.mobile thinks are multiple DataSources. DataSource then tries on line 1708 to evaluate the code fragment, which has unbalanced braces and blows up.

I'm not sure what the best way to attempt to resolve this issue is, but it's a blocker for development, and I haven't been able to think of a workaround yet.

[Isomorphic]

This should be fixed in the most recent nightly build. Please confirm.

[chrylis]

This should be fixed in the most recent nightly build. Please confirm.

The SmartGWT.mobile download URLs don't have any date/build information attached. Is the download content simply being replaced nightly with a new build?

[Isomorphic]

See smartclient.com/builds, nightlies are now available there.

[chrylis]

I'm trying to test this, but the GWT dev mode has a thoroughly evil and spiteful feature where it actively and specifically deletes any resources it doesn't like from the target directory--meaning that our dev configuration that has only the SmartGWT.mobile interface GWT modules gets our DataSource pieces (specifically including all of the built-in XML files that DataSourceLoader wants) blown away at launch. Do you have any best practices yet for getting the DataSourceLoader put in a common place so that projects that have frontends using both SmartGWT and SmartGWT.mobile can get the static loader resources unpacked and not erased by dev mode?

[chrylis]

(To rephrase the question: The static resources are getting pulled in to the dev-mode launch by the SmartGWTPro [in our case] GWT module, which is inherited by our SmartGWT UI but not SmartGWT.mobile. The DataSourceLoader wants to use ServletContext.getResource() to load the static XML files, but the embedded dev mode Jetty is buggy and won't look in jar files like it should, only in the deployment webapp directory. How do we get the static resources pulled in without inheriting the legacy SmartGWT module?)

[chrylis]

Problem fixed: It was a bad mismatch between GWT, Maven, and Eclipse. Basically, the GPE run configuration only looks for includable modules on the project's source path, and while m2e pretends to add src/main/resources as a source folder (and the gwt-maven-plugin archetype puts the GWT module files there), it also excludes everything, causing GPE to lose track of the modules. The solution is to tone down the exclude on src/main/resources so it no longer excludes the .gwt.xml files.

[chrylis]

Original bug is still blocking: Now I'm reliably getting a ClassCastException because apparently JSONUtils is assuming that it can cast anything it sees to a JavaScriptObject, and the new mobile DataSource class isn't one. Interesting part of the stacktrace:

java.lang.ClassCastException: com.smartgwt.mobile.client.data.DataSource cannot be cast to com.google.gwt.core.client.JavaScriptObject
    at com.smartgwt.mobile.client.json.JSONUtils.getPropertyAsJSO(JSONUtils.java)
    at com.smartgwt.mobile.client.json.JSONUtils.getPropertyValue(JSONUtils.java:144)
    at com.smartgwt.mobile.client.json.JSONUtils.toRecord(JSONUtils.java:42)
    at com.smartgwt.mobile.client.data.DataSource.fromConfig(DataSource.java:1841)

The code appears to be causing problems because the "inheritsFrom" field evaluates to a mobile DataSource object, and then JSONUtils assumes that anything that's on the right-hand side of a JSON statement must be either a JSON primitive or a JSO, when in fact the evaluation system has already identified the RHS as a nested DataSource.

I don't mean to be sarcastic, but is Isomorphic testing the mobile DataSource loaders against any test case using the sort of "inheritsFrom" setup that the DataSourceLoader generates? It seems that any DataSource using this feature would have triggered these bugs.

[Isomorphic]

This has now been fixed, please try tomorrow's nightly build.

[chrylis]

The nightly for 2012-08-16 appears to be working fine. Thanks for the fix to this; I can see from the code that it wasn't a trivial patch.