Interesting post from my colleagues from the US regarding Oracle Forms & Firefox 52:
As of March 7, 2017, Mozilla has released the newest release of Firefox, version 52. Similar to what Google Chrome did about a year or so ago, Mozilla has now disabled the NPAPI plug-in which is required to run anything with Java such as Oracle Forms without using Java Web Start. What will happen is if Firefox is updated to version 52 and you try to access Forms, you will see a blank screen which will result in the Forms application to not start at all.
Fortunately, Mozilla has realized that businesses still need to use services such as Java during this transition, so Mozilla has released the Firefox “Extended Support Release” for version 52. This is a version of Firefox which is used by companies and organizations which need support for running Java with the NPAPI plug-in especially for mass deployments. The current ESR version of 52 will continue to allow the use of the NPAPI plug-in for Java through May 2018. The download link (to download the 32-bit Firefox 52 ESR for Windows 32 and 64-bit machines) may be found here:
After this is installed on your PC, you will be able to run Forms using Firefox again without the need of Java Web Start. This is important for anyone who is still running Forms 11gR2 (or older) which has no support for Java Web Start. However, if you are running Forms 12c, you may use Java Web Start which allows you to run Java (required for running Oracle Forms) without the NPAPI plug-in. Java Web Start allows you to run Oracle Forms 12c from any web browser (Internet Explorer, Firefox, Chrome, Edge, etc.). If you decide to use Java Web Start, the Firefox ESR is not necessary.
Sources: https://support.mozilla.org/t5/Problems-with-add-ons-plugins-or/Why-do-Java-Silverlight-Adobe-Acrobat-and-other-plugins-no/ta-p/31069 and https://www.fxsitecompat.com/en-CA/docs/2016/plug-in-support-has-been-dropped-other-than-flash/
from Oracle Knowledgebase – PITSS America, LLC
During my work as an Consultant I’ve seen some Forms applications, where developers made their lifes easier by using the Oracle connect string to directly connect to the database when starting Forms application. The problem is that the password in most cases is entered in plain text as part of the formsweb.cfg. In this blog post I am going to show an Oracle database feature that enables you to combine comfort and security. This is most properly only a problem for forms applications without SSO.
Purpose for using the userid
In most cases the connect string was utilized in the formsweb.cfg parameter userid. Here you are able to specify a complete connect string, e.g. userid=user/pw@mydatabase. Why would connect that way to your application? Often it was a way to perform a connect to the database and have a user login afterwards. Some developers say it would be to complicated for the users to first type in the credentials for the db and then connect with their personal user. But this usage of the userid is not feasible. Which DBA wants to have a unencrypted database production password in any configuration file?
Oracle Database Wallet
To be able to use the connect string in a secure way – not also to login to the application but also to enable batch processing etc. you can use the oracle wallet. This is a feature from the oracle database.
There are quite some guides in the web on how to set up a wallet and add credentials to it. I found the following guide as most helpful:
After you have set up the wallet correctly, you are able to connect to the database without entering the username and password. Those information are now stored encrypted in the wallet. With /@TNS_NAMES_ALIAS you can directly connect to the database.
Using wallet in configuration
So if you really need to use the parameter userid (which I normally do not recommend) in
your formsweb.cfg you can now use the wallet instead of unencrypted password. Add userid=/@TNS_NAMES_ALIAS to directly connect to the application on startup. As mentioned in the linked blog above, the wallet is slightly safer – keep in mind that you have to ensure OS security.
The following text is from a knowledgebase entry from my colleagues from the US. It describes how you have to configure Forms & Reports to be able to use PITSS.CON with webstart. Since adding your jar-files to the extensions.jnlp is a general task when you want to use webstart in 12c, I thought that this could also be helpful for people that want to configure webstart for their application in 12c.
Oracle Forms 12c is the first version of Forms to be supported with the new Java Web Start functionality. This allows you to launch your Forms application using any certified browser including Google Chrome. PITSS.CON can also be configured to run with Java Web Start. To implement this functionality with PITSS.CON, you will need to run these steps:
- Open up formsweb.cfg located in %DOMAIN_HOME%\config\fmwconfig\servers\WLS_FORMS\applications\formsapp_12.2.1\config.
- Within your config section(s) for PITSS.CON, add the following parameters inside it:
- Save and close the file.
- Go to %ORACLE_HOME%\forms\java and open up extensions.jnlp in a text editor (make a backup of this file first).
- Look for <!– <jar href=”jacob.jar”/ –>. Uncomment this line. It should look like this: <jar href=”jacob.jar”/>
- NOTE: This fixes a Forms startup issue when using Java Web Start. Source: Oracle Support note 2083540.1
- Add the following lines for each of the PITSS.CON jar files (this will allow all jar files for PITSS.CON to be used while running Java Web Start):
- <jar href=”/forms/PitssJava/pitssicon.jar”/>
- The file should look like this:
- Save and close the file.
- Clear your Java cache on your PC where you plan to launch PITSS.CON.
- Launch PITSS.CON.
After completing the steps above, you should be able to use PITSS.CON using Java Web Start.
über Oracle Knowledgebase – PITSS America, LLC
There is a known SSL-related issue when you run Oracle Forms 12c using the Java Web Start functionality. What happens is when you launch your Forms application using Java Web Start using HTTPS, you will notice that the URL will change to using HTTP instead of HTTPS. In some cases, you may encounter the following error:
“ExitException: Unable to load resource: http://<host>:<HTTPS_PORT>/forms/java/extensions.jnlp”
HTTPS Java Web Start issue
To fix this problem, you will need to add the following parameter inside your config section in formsweb.cfg which is configured for Java Web Start:
HTTPS Java Web Start fix
After making this change, the Java Web Start session should maintain the SSL connection using HTTPS without this error appearing.
thanks to my colleagues from PITSS LLC via Oracle Knowledgebase – PITSS America, LLC
I’ve migrated my first Oracle Forms module last week. It is the first time for me to be part of a migration project. The colleagues that I am working with instead have a high experience when it comes to ADF and migrating Forms to this technology, while my focus the last couple of years was mostly Oracle Forms. I think that is a possible scenario for many projects, where the aim is to migrate Forms to ADF.
So how can Forms developers start to migrate their application? The first step for me was to gather information on ADF, its architecture and the basics. I tried this with some self training, online materials and the help of my colleagues. When I came to the point to migrate the first module by myself I used the Forms Developer & PITSS.CON to understand how the form worked before and how the workflow was. There are people out there, that tell you that tools won’t do the job for you – and I agree. But they can make your job as a developer much easier. My colleague Mathias Waedt has developed a plugin for JDeveloper, that helps you as a developer when struggling with a migration. It helped me to understand which objects in ADF have been generated and which not. It showed me, were I had to put my effort into. The plugin fetches its information from the PITSS.CON repository.
When the plugin is started it shows the basic information of the project like the database scheme, the names packages for the different objects (entity objects, view objects, etc.) and some other parameters. With a click on the details tab it is possible to see information of single forms. The form summary tab displays information regarding how many Forms objects already have been transformed to ADF components with PITSS.CON. This gave me a first overview of the upcoming work for that specific module. I saw, that most of the graphical objects were generated and only small modifications were neccessary here, while I had to modify the business logic that was formerly located in triggers and program units.
With a click on Form Details it is possible to see which objects have been generated and which not. So for me as a newbie it was a big relief to use this kind of a checklist.
You can see all the objects from Oracle Forms and the corresponding generated objects in ADF – with a doubleclick you will directly jump into the generated object (e.g. Java Bean). As a future functionality it is planned to mark the objects that were added by the developer and are considered to be done. So you can work your way through the module without the danger to forget a functionality that was present in Forms up to 100%. The plugin is currently in the beta phase.
Since I started developing Oracle Forms within the Forms Developer there has always been an issue that was quite annoying: The fact, that srolling in the object navigator is not possible. But there is a tool out there, which enables additional mouse support called KatMouse. It provides universal mouse scrolling – here the link to download the tool:
After the installation and start of KatMouse it is possible to use the mouse wheel in the Forms Developer which is not a big deal – but it makes life easier. Thanks to my colleague Peter Kopac for the hint.