[Isomorphic]

Ah, ok, there is in fact a bug in the server-side processing in the dev release. This will be fixed in tomorrow's build (Jun 7)

[tece321]

I am of the opinion that any datasource names or ids distributed by Isomorphic should have a very small likelihood of clashing with customer normal usage. While there appears to be a way to avoid client side ID clashes, you have not offered an equivalent for server side clashes.

There shouldn't be a datasource with a common ID of "Project" in the distribution. There must be many customers using that ID. It is peculiar that this did not become apparent before 12.1 releases. Nevertheless if I understand the problem I think Isomorphic should ensure that any distributed datasource should have a unique ID, client or server side.

[user316]

So we are wondering why we are seeing this problem only now? What could have changed in the framework version that would cause this? I looked at earlier SmartGWT versions and noticed that the Isomorphic Project.ds.xml still existed there. Did the load order of datasources change? If I simply revert back to 12.0 the problem goes away.

[user316]

Yes, that approach will only work for client-side collisions, if you're experiencing that.

Ah, ok. It's a server-side fetch which isn't working.

[user316]

The HTML file is here if you'd like to take a look: ChipSTA.html

[Isomorphic]

Yes, that approach will only work for client-side collisions, if you're experiencing that.

[user316]

I tried setting "window.isc_useSimpleNames = false;" inside of a <script> </script> tag in my header before the SmartGWT libraries are loaded, but it didn't fix the issue or make any difference. The only way I can seem to fix it is by renaming the internal SmartGWT Project.ds.xml or otherwise renaming our datasource.

[user316]

Yes, I saw that, but perhaps it's better if Isomorphic changes all the internal datasources to Isomorphic_*.ds.xml - for example, Isomorphic_Project.ds.xml? That way it would greatly reduce the likelihood of any conflicts?

edit: ok, I see what you mean, let me try the portal mode setting

[Isomorphic]

Did you see post #11 above?

[user316]

Just wanted to ask, is there any chance you could rename the internal SmartGWT "Project" datasource to something else? Isn't it likely that naming it something generic such as "Project" could conflict with a lot of apps that use SmartGWT?

[user316]

That's correct - this is a hack because it would be using internal properties.

Again, nothing would have worked, or even started up, without isomorphic_core_rpc.jar. Your results clearly indicate that .jar was present, although it may have been an older version. So you should look closely at your deployment scripts to understand what was going on.

Yes, it was a mistake in not updating the deployment script. I didn't realize that when running through Eclipse, the server-side uses the libraries from the WEB-INF folder and not from the Eclipse classpath.

[Isomorphic]

That's correct - this is a hack because it would be using internal properties.

Again, nothing would have worked, or even started up, without isomorphic_core_rpc.jar. Your results clearly indicate that .jar was present, although it may have been an older version. So you should look closely at your deployment scripts to understand what was going on.

[user316]

I'm not sure what our plans are right now as to whether we will use the short-term hack or not, but I am not seeing "framework.datasources" anywhere in my server.properties. Does that mean it is using some sort of hidden default definition to load in the framework datasources? I only see "project.datasources", which doesn't appear to be including the framework datasources such as the framework version of Project.ds.xml at all.

*Just* having mismatched client and server .jars probably doesn't explain the groupBy issues

I am fairly sure that we only had mismatched client and server .jar versions, specifically with the isomorphic_core_rpc.jar.

[Isomorphic]

Regarding isomorphic_core_rpc.jar (the post you edited away), just note that without this .jar, the server-side system won't function at all - nothing will work. So rather than just copying the wrong version, that result suggested duplicate .jars were around, so you might want to double-check on that. *Just* having mismatched client and server .jars probably doesn't explain the groupBy issues, but mixed versions of server .jars in the same deployment would.

Regarding the "Project" DataSource - note that you will only expose yourself to such possible conflicts if you start your DataSource IDs with a capital letter, so we would highly recommend changing the name.

A terrible short-term hack would be place your Project.ds.xml in a directory on its own, and put that directory in the framework DataSource search path first, by redefining framework.datasources in your server.properties file so that it is:

framework.datasources: path/to/dir/with/your/project/datasource, $isomorphicDir/system/schema

[Isomorphic]

Project is a Framework schema. Perhaps you want to run in portal mode?