ArcGIS runs with no license set

[RuslanSlobodyanik]

I am using ArcGIS runtime 10.1.1 on Red Hat Linux 6.3. ArcGISRuntime
appears to initialize the JMap and run fine without license even with a set
invalid license string, and even deployed to a computer with no ESRI
software installed. Example:

main(){

authorizeLicenses();

JMap map=new JMap(); //this works without licenses set

}

authorizeLicenses(){

ArcGISRuntime.setLicense("Invalid license string");
//test initialization with invalid license string
ArcGISRuntime.initialize();//no exception thrown here

if(ArcGIRuntime.getLicenseStatus()==LIcenseStatus.NONE||ArcGIRuntime.getLice
nseStatus() ==LIcenseStatus.INVALID||!ArcGISRuntime.isLicensed()){

//initialize ArcGIS from authorization.ect file

}else{

//pases to here!

}

How do I detect invalid state to let the user know that the application
needs to be licensed?"

[EricBader]

2 Questions:

Was there ever any Esri software installed on the target machine in the past?

Does ArcGIRuntime.getLicenseStatus() return anything at all?

[CarlosColón-Maldonado]

I'm having similar issues. The isLicensed() method returns false, but the JMap still gets instantiated and the application starts in Red Hat Linux Sysem (RHELS) Version 6 Update 3. This does not occur in Windows. This occurs on a development box with the SDK installed, but the application behaves similarly when deployed to a RHELS 6.3 box with no ArcGIS Runtime SDK installed (ever).

We are forcing shutdown on no authorization (.ecp) file found, and parsing these authorizations files in order to set them at start-up, but we'e finding that even invalid strings do not prevent JMap instantiations. Are users of the API required to check to ensure the libraries are properly licensed on applications' start-up or else?

I don't have a way of knowing if the application is being licensed with a development license or not unless I set it myself with a default string. Is this good practice? The behavior of the Linux-flavored API appears to have a bug to me. I was under the impression that the API would self-protect itself if licensing did not occurred on deployed applications (like the Windows version).

[RuslanSlobodyanik]

Eric,

2 Questions:

Was there ever any Esri software installed on the target machine in the past?

Does ArcGIRuntime.getLicenseStatus() return anything at all?

There was no Esri product installed on the target machine at any time, this was a fresh Linux Redhat box.
ArcGIRuntime.getLicenseStatus() returns NOT_VALIDATED, but this does not prevent Esri component from initializing

[EricBader]

And you've added a basemap, or some layers, or a Web Map to it and it initializes?

[MarkBaird]

I'm afraid it's a bug with Linux deployments.  It's fine in windows.

You will still need to properly license your application properly especially for "Standard" deployments otherwise your local server will fail (as it does in Windows if you don't have the correct license).

Mark

[RuslanSlobodyanik]

Eric,

And you've added a basemap, or some layers, or a Web Map to it and it initializes?

That's correct. I'm using tilepackages created from CDRG rasters.

I'm afraid it's a bug with Linux deployments.  It's fine in windows.

You will still need to properly license your application properly especially for "Standard" deployments otherwise your local server will fail (as it does in Windows if you don't have the correct license).

Mark

Mark,
My application is runs locally on desktop, and I believe it uses local server as such.(?) It does not seem to matter if I set license or not, as shown in code. The application runs map tile packages, zooms, pans, does map calculations, etc, another words has full Arcgis functionality as far as I can see. Can you explain how the scenario you describe that would make local server crash with incorrect license is different from mine?
I had to make application read license string from file and prevent it from starting if authorization file is missing. However just setting incorrect license string or none, does not make a difference. Is this just me running in this situation, or is this a bug, and if so would it be fixed in later version? It seems to me ineffective to prevent unauthorized use the way I do it now.

[CarlosColón-Maldonado]

I'm afraid it's a bug with Linux deployments.  It's fine in windows.

You will still need to properly license your application properly especially for "Standard" deployments otherwise your local server will fail (as it does in Windows if you don't have the correct license).

I'm not managing LocalServer or LocalService objects in code, but allowing the map to handle ArcGISLocalTiledLayer objects internally, so is that the difference?

We're eventually going to move to ArcGISDynamicMapServiceLayer objects in order to handle adding and removing rasters unto and off mosaic datasets, so we need to get this right so we wouldn't experience sudden problems with the local server when we do. We also want to simply have users get their own "authorization.ecp" files from Esri so our application can consume and authorize the API with them. Though similarly to the string from the deployment tool, they don't seem so user-friendly to handle. I gathered so far that the main license must be set first before any extensions, if any. Any suggestions on how to handle these files?

[CarlosColón-Maldonado · Accepted solution]

I'd like to report that, after working closely via shared session with ESRI customer service representatives, it turns out that the deployment folder created for the application did not have all of the necessary local server components, which prompted the failure of license string authorizations (it did not find the libraries it needed to authorize for use).

It took a very long time to figure this out because it had been long since we created the deployment folder before we improved the application to use more advanced components. This is a lessons learned that it is best to include all components up-front, and at every upgrade, if the application will eventually require the SDK's advanced features, even though the functions have yet to be implemented.