Layer loadError with JavaScript 3.12 API

[MichaelLundin]

I'm working on upgrading to the 3.12 version of the ArcGIS JavaScript API, and I'm hitting a bit of a snag. If I create a separate page and add a layer to a map everything works fine, so I know I have the API set up correctly. However, in my application, there comes a point where if I create an ArcGISTiledMapServiceLayer, it is immediately created with a loadError of "Error: no match found". The error occurs before the layer is added to the map (and even if it's never added to the map). I'm trying to create the smallest possible set of code for reproducing the problem, but haven't been able to isolate where it's happening. I apologize for not including any code samples, due to that, and will continue to try and get to a point where I can.

More what I'm wondering is if anyone has hit this error before, and what it might mean. To make sure it wasn't my layer that was causing the problem, I have used multiple layers and I am currently trying with one of the ESRI base layers:

var layer = new ArcGISTiledMapServiceLayer('http://services.arcgisonline.com/ArcGIS/rest/services/World_Topo_Map/MapServer');

Using Fiddler, I've also noticed that when I do this, no http request is made to the endpoint.

Any help on this would be greatly appreciated.

Thanks.

[JeffPace]

Usually this kind of this is because of out of order declares. Have you added any new classes to your "require" without adding the alias to the "function"?

[MichaelLundin]

Jeff,

I wondered about that, too, but have checked to make sure that the require statements line up with the aliases. Also, in what confuses me the most, in my JavaScript file that initializes things, if I create the layer in a function early in the process, the layer is created without error. However, in another function (in the same JavaScript file, and the same set of requires/aliases) that gets called later in the lifecycle, the layer gets created with the loadError.

[MichaelLundin]

And, also, if I switch back to the older JavaScript API (3.9 or 3.11), things work fine.

[JeffPace]

So simply changing from 3.12 to 3.11 fixes it?

1.Are you using https and http combined?

2. do you specify a baseUrl in your dojo.config?

3. are you using sync or async in dojo.config

[MichaelLundin]

Jeff,

Correct, changing from 3.12 to 3.11 allows the application to run as usual, as does using 3.9. However, a simple test page that creates a map and adds a layer also works in 3.12 (using the same dojoConfig).

To answer your other questions:

1. I am using just http.

2. I do not specify a baseUrl in the dojoConfig.

3. async is set to false in the dojoConfig

[MichaelLundin]

Okay, so I've identified the cause. I've attached an HTML file that will reproduce the problem I'm seeing.

The page will fail to load the map as-is.

It is related to using dojo's xhrPlugins.addCrossSiteXhr method. Before that method is used, layers work fine. After that method is used, layers fail. It looks like that is stripping away some XHR references from the AdapterRegistry that the layers don't like having removed. If you change the version to 3.11, you'll still get an error in the JavaScript console, but the map will function.

That was the part I was missing. In our full application, it looks like after some widgets are initialized, but before the page is fully loaded, we're using this method to allow for push notifications. Any layers created after that section of code would fail to load, anything before that section worked fine. If I remove that call, the application functions.

Now to figure out how to work around it.

[JeffPace]

can you move loading the xhrPlugins.addCrossSiteXhr to the onLayersAdded event so that it doesnt load until after the map has finished loading all layers?

[MichaelLundin]

Not really. I could with the first layers to be added, but there are other (more dynamically created) layers that might be added later, which would be after the call to addCrossSiteXhr.

I'm going to see if there is an alternative to addCrossSiteXhr or if there's a way to make it work nicer with the layers.

It does seem like something changed in the ArcGIS API at 3.12 with this behavior, as the dojo versions between 3.11 and 3.12 are the same.

[KellyHutchins]

Michael,

At version 3.11 of the JSAPI we didn't list services.arcgisonline.com in corsEnabledServers. So the layer is loaded via JSONP instead of XHR so the code path where dojox/xhrplugin is executed isn't being used and the layer loads and displays successfully .  The 'no match found' errors will appear in the console when the layer makes a request to get dynamic attribution and when esri/request fetches services.arcgisonline/rest/info to detect CORS.

At 3.12 we added services.arcgisonline.com to corsEnabledServers so the layer now uses the XHP code path which means xhr plugin executes. This fails because services.arcgisonline.com hasn't been registered with the xhrPlugin and because the plugin is not aware of services.arcgisonline the request fails.

To fix this issue your app will need to register all hosts from corsEnabledServers with the xhrPlugin. Here's an example that shows how to do this.

JS Bin - Collaborative JavaScript Debugging

Are you using xhrPlugin because you are using dojo/xhr for some reason? If so is it possible in your use case to use esriRequest + corsEnabledServers? Doing so will also resolve the problem.