Forum Stats

  • 3,722,809 Users
  • 2,244,417 Discussions


Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

FSAL problems on Windows 10

Peter_S Member Posts: 29 Red Ribbon

Hi all,

end of last year we migrated our Forms applications to FSAL. In principle the applications are working fine. But with one application we observe a strange behaviour on some devices:

The application uses a self developed Java bean which implements a Gantt chart based on JViews. This application is working fine on most devices. But on some devices we observe the following hehaviour when the user calls the form which contains this bean:

  • Custom events raised by the bean are not forwarded any more.
  • Even if the user clicks on a standard Forms button (like closing the application or leaving the form) nothing happens.

It seems as if events are not forwarded any more. All devices are devices with Windows 10 operating system (the ones where the application is working fine and the ones where the applications shows this behaviour).

We use Weblogic as middleware and Java 1.8. (221, 64bit) on the clients.

Does anyone have an idea what might cause this behaviour?

Thanks and with best regards



  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Member Posts: 6,490 Employee

    Although I'm not prepared to rule anything out at this point because I don't have all the information, it is highly unlikely that the root cause of the problem is the result of using FSAL. The application has no awareness that it is running in FSAL, the browser, or JWS.

    Your limited description of the problem seems to suggests the JVM is crashing as a result of something your bean is doing. It also might suggest that you generated the module (FMX) on one platform (e.g. Windows) then moved it to another (e.g. Linux) in order to run it.

    Things to consider:

    .1. How old is your bean code and when were its JARs created? If they are fairly old, it might be time to rebuild both the CLASS files and the JAR(s) using a newer JDK in the v8 family.

    .2. Be sure to properly sign your JAR files using a trusted and known certificate. Do not use self-generated signatures unless the self-generate cert chain has been imported into the local keystore. I strongly recommend using real certs (e.g. Verisign, Thawte, etc).

    .3. Be sure to generate X files on the server that is hosting them. The Forms X files are not platform portable.

    .4. If you are currently running FSAL with javaw, don't. Use java.exe and leave the console/shell window open so that any errors are displayed. Share that output here.

  • Peter_S
    Peter_S Member Posts: 29 Red Ribbon
    edited February 1

    Hi Michael,

    sorry for the lack of information.

    We also do not think that the root cause is the application itself because the application is running fine on most devices. There are only few devices where the application behaves as described and at the moment we do not have any idea what might cause this behaviour - maybe a special setting on these devices, network, etc. So maybe someone has an idea what we need to check.

    Here are some additional information (hope they help):

    • At the moment we are in a migration phase. This means we provide both mechanisms: Java PlugIn (Java 1.8.0_221 32bit) and FSAL (Java 1.8.0_221 64bit). Therefore we created two separate configurations in formsweb.cfg. Both use the same .fmx, .plx, .mmx. and jar-files. The plan is to deactivate the PlugIn mechanism this year.
    • On all devices Windows 10 is installed.
    • All Forms related X-Files are generated on the server where the Weblogic server is installed which is a Unix system.
    • On those devices where the application shows this strange behaviour when using FSAL the application is running fine when using the PlugIn mechanism.
    • The self developed beans have been recompiled this year.
    • The used certificates are also valid and not self developed.
    • FSAL is started using java. The output is routed into a separated log file (we wrapped the Java call into a Dotnet starter application),but the log file does not show any error or additional output.
    • For test purpose we have allready reinstalled Java on one device where this behaviour occurs but this had no effect.
    • I do not think that the JVM crashed completely because the bean itself behaves correctly (e.g., tooltips are displayed when the user moves over an element in the bean, context menus are shown when the user does a right click, the user is able to move elements in the bean which is controlled by the bean). But when the user initiates an action where a custom event is raised (.e.g. in order to open a forms dialog) nothing happens. Also the standard events (like closing the the dialog by clicking on "x" at the top right corner) are not executed any more. As mentioned the log files do not show any error.

    Thanks and with best regards


  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Member Posts: 6,490 Employee

    It the problem is not reproducing on some machines but does reproduce on others, what is the difference? Are they all the same OS, version, and architecture (32 or 64 bit)?

    Does your custom bean access any external libraries (e.g. .dll)? If so, you will need to use a JRE of the same architecture as the external library was designed. In other words, you will not be able to use a 64 bit JRE if the external libraries were created for 32 bit (and visa-versa).

    I would also recommend that for the sake of troubleshooting the FSAL be started using a direct command line call and not be launch using a custom executable. It is possible that the custom executable is either causing the problem or masking the root cause of the problem.

  • Peter_S
    Peter_S Member Posts: 29 Red Ribbon

    After some additional investigations we found that a NullPointerException is thrown in the bean on the affected devices and not caught correctly so that we were able to provide a fix for this. But at the moment it is still not clear why this behaviour is not reproducible on most devices the application is running on. We found that the exception is thrown when the user activates a context menu by clicking the right mouse button. On these devices the stack trace after having clicked the right mouse button is complete different than the stack trace on the other devices which at the end lead to the NullPointerException. There must be a special settting on these laptops which causes this different behaviour.

    But this is not a Forms issues and we need to analyse this in more detail separately.

    Thank you for your help.

  • Michael Ferrante-Oracle
    Michael Ferrante-Oracle Member Posts: 6,490 Employee

    Thank you for the update. Although not a Forms issue, please let us know if you find the reason it only reproduces on some machines. I'm sure other might be able to benefit from the findings.

Sign In or Register to comment.