No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Strange datasource issue when upgrading to 12.1

    I have started testing 12.1pro and have come across a strange occurence:

    I have a datasource called "image" that i define in image.ds.xml. This works fine in 6.0.

    In 12.1 i get an error, "Unable to load DataSource for ID: image", in DataSourceLoader.processRequest(295).

    If i copy the xml into a new file "imagex.ds.xml" and try to load that one, it loads fine.

    Is "image" some sort of reserved name or other in 12.0/1? This is very puzzling.

    Please show the rest of the relevant logs (for DataSourceLoader).


      OK. So first, on the first request to the server after startup, i can see that the xml parser and DataSourceLoader, for example:

      2020-04-28 19:46:14.695 DEBUG com.isomorphic.xml.XML - Parsed XML from /Users/mathias/Library/Caches/JetBrains/IntelliJIdea2020.1/gwt/....../run/www/ds/nfctag.ds.xml: 3ms
      2020-04-28 19:46:14.703 DEBUG c.i.servlet.DataSourceLoader - For DataSource 'nfctag', got instanceId 89
      Have the datasources printed out, but my image.ds.xml is NOT one of them even though the file is there, as it always has been.

      Then i get this error:
      2020-04-28 19:40:03.167 ERROR c.i.servlet.DataSourceLoader - Exception while attempting to load a DataSource
      javax.servlet.jsp.JspException: Unable to load DataSource for ID: image
          at com.isomorphic.servlet.DataSourceLoader.processRequest(
          at com.isomorphic.servlet.DataSourceLoader.doGet(
          at javax.servlet.http.HttpServlet.service(
          at com.isomorphic.servlet.BaseServlet.service(
      i set the loglevel to TRACE for com.isomorphic.servlet.DataSourceLoader, but it doesn't seem to log much except the above.


        Something else is fishy here... I have another datasource, "user", defined in user.ds.xml, which of course also worked in 6.0. Now, in 12.1 i got a strange popup error complaining that fields i am defining in my editor doesn't exist in the datasource ("name1"). After trying to debug without success, i simply took hold of the "user" DataSource object and printed its fields.
        This is what i got:
        Datasource is user, #fields: 8
        -> userId
        -> email
        -> firstName
        -> lastName
        -> title
        -> phone
        -> superUser
        -> roles
        Where do these come from? These fields are not at all what i have defined in my user.ds.xml. I checked the network traffic, and the stuff returned from the DataSourceLoader is correct, i.e. my DataSource with ID "user" has the correct fields there. But when i do DataSource.get("user") and print out the fields, i get the above 8.

        Again, the only thing i have done to our project, so far, is change my dependency and fixed compilation errors.


          This is part of the new client-side Authentication system, which just provides a standard place to put user and role information for client-side usage like disabling or hiding controls that don't apply for the current user. We'll link you to the SmartClient docs for this, as we've just found that some of the new doc isn't appearing properly in SGWT docs:

          However, this should not interfere with your "user" DataSource - once you define your "user" DS, that would be what is returned.

          Are you on the latest patched build?

          Are you doing anything unusual in your initialization order, like perhaps you create some components, then load the "user" DS, then other components are created - anything like that?


            I'm on 12.1-p20200421.

            Something is not working right, since i can see in the network logs that the loader is returning all datasources, if i fetch another datasource, it exists and has the correct fields, but if i fetch the "user" datasource it is your custom Datasource-Auth object.

            I am doing stuff in various orders for sure. I have an on-demand tab set that initializes tabs when user clicks on them, but i do not understand how that should affect the datasources. I am not sure what you mean by "loading" the user DS, aren't they loaded automatically by the DataSourceLoader script? I do not wait to check to see if datasources have loaded before i initialize my app if that's what you're asking.

            I have had the this entrypoint loading process since 2011, it feels really funky that some under-the-hood Authentication logic interferes with my datasources.


              Just to give you some additional info about our pageload:

              1. The datasourceload is defined in our jsp landing page as per standard procedure:
              <script src="xxx/sc/DataSourceLoader?locale=<%=locale%>&dataSource=thedatasources">
              2. In our Entrypoint, the first thing that happens, before we initialize anything, do any ui code, is this:
              public void onModuleLoad() {
                      try {
                          MyDSRequest reqProps = new MyDSRequest(ClientServerConstants.USER_OPERATIONID_LOGGEDIN, true);
                          userDS = DataSource.get(ClientServerConstants.DS_USER); //this is "user"
                            userDS.fetchData(null, (dsResponse, o, dsRequest) -> {
              //here in the response i set up the application              
              One guess could be that onModuleLoad is executed before your DataSourceLoader returns? I'm just guessing...


                One more item of debugging feedback:

                I went ahead and renamed my user.ds.xml file to "useradm", and did the same in the datasourceloader, and client side code. It then started working as before.

                So, to me these issues are related to some sort of bug regarding how you name your datasources? I do want to continue to be able to choose my datasource names... :)


                  So the intent was that this built-in DataSource could not possibly collide with any user DataSource, but we think we understand how you could end up with the problem you reported, and we're fixing it in a way where the order of operations cannot possibly matter.


                    Great. Do you have any feedback on my "image" datasource problem above?


                      We're separately trying to see if that one can be reproduced on our end. We don't yet have a theory on that one (there's no built-in "image" or "Image" DataSource), but regardless if there's a collision there that messes with a DataSource of your own named "image", we'll fix the problem.


                        We've looked into why DataSource ID image wasn't working. Sorry, this was due to an over-aggressive optimization. We've made a fix to SGWT/SC 12.1p and newer branches that should be in the nightly builds dated 2020-05-06 and beyond.


                          OK. Does that fix include the "user" DS naming issue as well?


                            That was already fixed a couple of days back.


                              I'm trying to get the 2020-05-06 build you mention above. It says that nightlies build at 6 AM but i can't find it?