Uploaded image for project: 'Pivot'
  1. Pivot
  2. PIVOT-949

bxml:script using js file (absolute path) doesn't work

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.3, 2.0.4
    • Fix Version/s: 2.1, 2.0.5
    • Component/s: core-serialization
    • Environment:
      Windows 7
      Java 7 Update 67, Java 8 Update 20

      Description

      Hi,

      I use in my bxml files lines like:
      <bxml:script src="/gui/pivot/scripts/variables.js" />
      which loads some variables that I can use in the file by calling them like $icon

      But when using a Java version higher than 6, I get this error:

      org.apache.pivot.serialization.SerializationException: Value "icon" is not defined.
      at org.apache.pivot.beans.BXMLSerializer.processAttributes(BXMLSerializer.java:1093)
      at org.apache.pivot.beans.BXMLSerializer.processStartElement(BXMLSerializer.java:819)
      at org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:443)
      at org.apache.pivot.beans.BXMLSerializer.processStartElement(BXMLSerializer.java:910)
      at org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:443)
      at org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:634)
      at org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:607)
      at dcp.main.gui.pivot.Master.startup(Master.java:190)
      at org.apache.pivot.wtk.DesktopApplicationContext$2.run(DesktopApplicationContext.java:641)
      at org.apache.pivot.wtk.ApplicationContext$QueuedCallback.run(ApplicationContext.java:1607)
      at java.awt.event.InvocationEvent.dispatch(Unknown Source)
      at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
      at java.awt.EventQueue.access$400(Unknown Source)
      at java.awt.EventQueue$3.run(Unknown Source)
      at java.awt.EventQueue$3.run(Unknown Source)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
      at java.awt.EventQueue.dispatchEvent(Unknown Source)
      at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
      at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
      at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
      at java.awt.EventDispatchThread.run(Unknown Source)

      And my application shows a popup window with the message:
      Value "icon" is not defined.

        Activity

        Hide
        smartini Sandro Martini added a comment -

        Hi,
        are you sure you are using Pivot-2.0.3 ? And are you sure that with Java 6 all is good while using Java 7 not ?
        Could you attach here a minimal sample of your project ?

        Anyway it's strange ... because absolute paths in bxml is a thing changed many time ago ... I suggest to use a relative path (as you can find in all our samples and tests). Under our tests subproject you can find some examples, like pivot_843.bxml, and a not-so-trivial example JavascriptConsoleTest and related files like javascript_console_test.bxml .

        For some info take a look here:
        http://pivot.apache.org/tutorials/bxml-primer.html

        Let us know if you still have problems, or in a few weeks I'll close this issue ...

        Show
        smartini Sandro Martini added a comment - Hi, are you sure you are using Pivot-2.0.3 ? And are you sure that with Java 6 all is good while using Java 7 not ? Could you attach here a minimal sample of your project ? Anyway it's strange ... because absolute paths in bxml is a thing changed many time ago ... I suggest to use a relative path (as you can find in all our samples and tests). Under our tests subproject you can find some examples, like pivot_843.bxml, and a not-so-trivial example JavascriptConsoleTest and related files like javascript_console_test.bxml . For some info take a look here: http://pivot.apache.org/tutorials/bxml-primer.html Let us know if you still have problems, or in a few weeks I'll close this issue ...
        Hide
        jackred Said SAID EL IMAM added a comment - - edited

        Hi,
        Thank you for your reply,
        Sorry I made a mistake, actually it works just fine in Java 6 as well as 7. The problem I described is just for Java 8...

        I tried changing all paths to relative ones, but the problem persists on Java 8.

        Is there any known issues to Pivot compatibility with Java 8 ?

        Show
        jackred Said SAID EL IMAM added a comment - - edited Hi, Thank you for your reply, Sorry I made a mistake, actually it works just fine in Java 6 as well as 7. The problem I described is just for Java 8... I tried changing all paths to relative ones, but the problem persists on Java 8. Is there any known issues to Pivot compatibility with Java 8 ?
        Hide
        smartini Sandro Martini added a comment -

        Up to now I didn't tried Pivot with Java 8 (I just installed a JDK 8 Update 5 in the hope that most big issues should already be fixed in it ), and I should start to make some test in next weeks ... the only problem that we had with Java 8 up to now was PIVOT-939 in our Jenkins builds (but could be due to a not-optimal configuration of jobs, I still have to look better at it).

        Note that in Java 8 there should be some changes/restrictions on using plugin classes (for applets) so I expect some changes here ... anyway now both issues are in my todo list for 2.1.0 with high priority.

        Let's update, if you have some info be free to post here.
        Thanks for now. Bye

        Show
        smartini Sandro Martini added a comment - Up to now I didn't tried Pivot with Java 8 (I just installed a JDK 8 Update 5 in the hope that most big issues should already be fixed in it ), and I should start to make some test in next weeks ... the only problem that we had with Java 8 up to now was PIVOT-939 in our Jenkins builds (but could be due to a not-optimal configuration of jobs, I still have to look better at it). Note that in Java 8 there should be some changes/restrictions on using plugin classes (for applets) so I expect some changes here ... anyway now both issues are in my todo list for 2.1.0 with high priority. Let's update, if you have some info be free to post here. Thanks for now. Bye
        Hide
        smartini Sandro Martini added a comment -

        Note that in BXMLSerializer (since many time, could be since 2.0) on include and src attribute values, the initial '/' char if given it's stripped out ... probably we should update BXML Primer ( http://pivot.apache.org/tutorials/bxml-primer.html ) with this info, and write even that usually it's better to set that value in a relative way (using ../ if needed).

        I have to make other tests, because this is strange; anyway I just installed Oracle JDK 8 Update 20, I'll make some test with it.

        Show
        smartini Sandro Martini added a comment - Note that in BXMLSerializer (since many time, could be since 2.0) on include and src attribute values, the initial '/' char if given it's stripped out ... probably we should update BXML Primer ( http://pivot.apache.org/tutorials/bxml-primer.html ) with this info, and write even that usually it's better to set that value in a relative way (using ../ if needed). I have to make other tests, because this is strange; anyway I just installed Oracle JDK 8 Update 20, I'll make some test with it.
        Hide
        smartini Sandro Martini added a comment -

        Revision 1636826: Just committed (at the moment only in trunk) a test application, but I see the same issue even with an recent Java 7 (Update 67) too ... I guess if this is due to some backport from java 8 to Java 7 ...

        Anyway, someone still need to refer to scripts in an absolute way (URI start with a "/") ? Because in all our sources it has never used ...
        Note that with relative URI all works (for example "../name.js") it works.

        Unless objections I could do a simple fix in BXMLSerializer that (as done in other parts inside it) drop the char "/" if found as first char in the src attribute of bxml:script ...
        And then I can update with this info even our "BXML Primer" page (even for the relative URI trick).

        Last, trying to use a page variable in src attribute I just see that here it doesn't work (but a similar trick works in the include attribute like in the javascript_console_test.bxml), I have to check even this (or at least write somewhere this info).

        What do you think ?

        Show
        smartini Sandro Martini added a comment - Revision 1636826: Just committed (at the moment only in trunk) a test application, but I see the same issue even with an recent Java 7 (Update 67) too ... I guess if this is due to some backport from java 8 to Java 7 ... Anyway, someone still need to refer to scripts in an absolute way (URI start with a "/") ? Because in all our sources it has never used ... Note that with relative URI all works (for example "../name.js") it works. Unless objections I could do a simple fix in BXMLSerializer that (as done in other parts inside it) drop the char "/" if found as first char in the src attribute of bxml:script ... And then I can update with this info even our "BXML Primer" page (even for the relative URI trick). Last, trying to use a page variable in src attribute I just see that here it doesn't work (but a similar trick works in the include attribute like in the javascript_console_test.bxml), I have to check even this (or at least write somewhere this info). What do you think ?
        Hide
        smartini Sandro Martini added a comment - - edited

        First part of the patch, resolving main problem.
        Added a fallback in case the given src attribute starts with "/" and the desired resource has not been loaded by the classloader (this could be something changed in recent Java 7/ 8 versions).
        Add even some small changes to use the Java 7 try-with-resources.

        Unless objections I'll commit this this week.
        Of course the backport in 2.0.x will be without the try-with-resources changes, to keep it compatible even with Java 6.

        After this, I'llgo to the second part, and try to extend this a little and see if possible to load an src resource from a script variable (see in related test bxml file).

        Show
        smartini Sandro Martini added a comment - - edited First part of the patch, resolving main problem. Added a fallback in case the given src attribute starts with "/" and the desired resource has not been loaded by the classloader (this could be something changed in recent Java 7/ 8 versions). Add even some small changes to use the Java 7 try-with-resources. Unless objections I'll commit this this week. Of course the backport in 2.0.x will be without the try-with-resources changes, to keep it compatible even with Java 6. After this, I'llgo to the second part, and try to extend this a little and see if possible to load an src resource from a script variable (see in related test bxml file).
        Hide
        rwhitcomb Roger Whitcomb added a comment -

        I think I may know the underlying reason for this, after getting a similar error in one of our BXML files that had this script in it:
        <bxml:script>
        importClass(org.apache.pivot.wtk.Button);
        function isSelected(state)

        { return state == Button.State.SELECTED; }

        </bxml:script>
        We would get an error with Java 8 (but not with Java 7): "Mapping function "isSelected" is not defined.".
        After much debugging and research I found several resources that helped to fix the problem:
        https://wiki.openjdk.java.net/display/Nashorn/Rhino+Migration+Guide
        It turns out that the new Nashorn script engine in Java 8 does not directly support the Rhino function "importClass". Instead you need to load a compatibility script first:
        try

        { load("nashorn:mozilla_compat.js"); }

        catch (exception) { }
        There is also a difference in the way the global namespace is stored under Nashorn. So, I am preparing a patch to BXMLSerializer to fix this. This will do two things:
        1) If "nashorn" is detected as the script engine, run this script fragment before any user scripts so that "importClass()" and etc. are available (to maintain backward compatibility).
        2) Do the namespace switching (basically load the "nashorn.global" element into the script GLOBAL_SCOPE before invoking functions).

        I will have a separate patch for this in a couple of hours after I finish testing with my application.

        I have no comment, however, on your proposed patch, Sandro. If it helps, great, but I suspect this other problem I have just described is also causing problems.

        Show
        rwhitcomb Roger Whitcomb added a comment - I think I may know the underlying reason for this, after getting a similar error in one of our BXML files that had this script in it: <bxml:script> importClass(org.apache.pivot.wtk.Button); function isSelected(state) { return state == Button.State.SELECTED; } </bxml:script> We would get an error with Java 8 (but not with Java 7): "Mapping function "isSelected" is not defined.". After much debugging and research I found several resources that helped to fix the problem: https://wiki.openjdk.java.net/display/Nashorn/Rhino+Migration+Guide It turns out that the new Nashorn script engine in Java 8 does not directly support the Rhino function "importClass". Instead you need to load a compatibility script first: try { load("nashorn:mozilla_compat.js"); } catch (exception) { } There is also a difference in the way the global namespace is stored under Nashorn. So, I am preparing a patch to BXMLSerializer to fix this. This will do two things: 1) If "nashorn" is detected as the script engine, run this script fragment before any user scripts so that "importClass()" and etc. are available (to maintain backward compatibility). 2) Do the namespace switching (basically load the "nashorn.global" element into the script GLOBAL_SCOPE before invoking functions). I will have a separate patch for this in a couple of hours after I finish testing with my application. I have no comment, however, on your proposed patch, Sandro. If it helps, great, but I suspect this other problem I have just described is also causing problems.
        Hide
        rwhitcomb Roger Whitcomb added a comment -

        Here is the reference from which I was able to figure out the use of the "nashorn.global" namespace:
        https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes

        Show
        rwhitcomb Roger Whitcomb added a comment - Here is the reference from which I was able to figure out the use of the "nashorn.global" namespace: https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes
        Hide
        smartini Sandro Martini added a comment -

        Hi Roger,
        I think you catch the original question of this issue: very well .
        Yes my patch could mitigate a secondary (but wrong) effect, so I'm committing it (and its second part in a few days).

        Waiting for your patch, to make some test ... thanks for now.

        Show
        smartini Sandro Martini added a comment - Hi Roger, I think you catch the original question of this issue: very well . Yes my patch could mitigate a secondary (but wrong) effect, so I'm committing it (and its second part in a few days). Waiting for your patch, to make some test ... thanks for now.
        Hide
        smartini Sandro Martini added a comment -

        Just committed (both in trunk and in 2.0.x) the second part of the fix, or better this time a small enhancement: the ability to use a script variable to store the value to use in src attribute.

        Roger, be free to reassign to yourself if you plan to do other enhancements here, or if you prefer to add a new issue specific tell me so I can mark this issue as resolved. Thanks. Bye

        Show
        smartini Sandro Martini added a comment - Just committed (both in trunk and in 2.0.x) the second part of the fix, or better this time a small enhancement: the ability to use a script variable to store the value to use in src attribute. Roger, be free to reassign to yourself if you plan to do other enhancements here, or if you prefer to add a new issue specific tell me so I can mark this issue as resolved. Thanks. Bye
        Hide
        smartini Sandro Martini added a comment -

        Hi Roger, some update on your tests ?

        Show
        smartini Sandro Martini added a comment - Hi Roger, some update on your tests ?
        Hide
        rwhitcomb Roger Whitcomb added a comment -

        Yes, I am now officially totally confused. With my changes (apparently) working, I tried tidying up the code for commit and then it stopped working. Now I cannot get back to working code. The error I'm getting has to do with lack of permission to access the "user.dir" property, from deep inside the Nashorn code trying to load the "nashorn:mozilla_compat.js". It is (apparently) trying to construct a File object from this string, which is dumb, since it is a resource in the nashorn.jar file. And why it doesn't have permission to access "user.dir" property is a mystery to me, since all my other (signed jar) code DOES have permission.

        I will come back to this in a couple of weeks .... (after vacation).

        Show
        rwhitcomb Roger Whitcomb added a comment - Yes, I am now officially totally confused. With my changes (apparently) working, I tried tidying up the code for commit and then it stopped working. Now I cannot get back to working code. The error I'm getting has to do with lack of permission to access the "user.dir" property, from deep inside the Nashorn code trying to load the "nashorn:mozilla_compat.js". It is (apparently) trying to construct a File object from this string, which is dumb, since it is a resource in the nashorn.jar file. And why it doesn't have permission to access "user.dir" property is a mystery to me, since all my other (signed jar) code DOES have permission. I will come back to this in a couple of weeks .... (after vacation).
        Hide
        smartini Sandro Martini added a comment -

        ok, don't worry ... so what do you think if I resolve this issue and we handle the nashhorn-related fixes in a new one ?

        Show
        smartini Sandro Martini added a comment - ok, don't worry ... so what do you think if I resolve this issue and we handle the nashhorn-related fixes in a new one ?
        Hide
        rwhitcomb Roger Whitcomb added a comment -

        Yes, I think that would be wise: resolve this issue and we'll make a new issue for the nashorn-related bugs.

        Show
        rwhitcomb Roger Whitcomb added a comment - Yes, I think that would be wise: resolve this issue and we'll make a new issue for the nashorn-related bugs.
        Hide
        smartini Sandro Martini added a comment -

        Resolved, the part related to Nashhorn (the JavaScript interpreter of Java 8) will be handled in another issue linked to this.

        Show
        smartini Sandro Martini added a comment - Resolved, the part related to Nashhorn (the JavaScript interpreter of Java 8) will be handled in another issue linked to this.

          People

          • Assignee:
            smartini Sandro Martini
            Reporter:
            jackred Said SAID EL IMAM
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development