In this post, I will explain the complicated process for making multiple Java plugins to work on the Same Windows PC which is used by the EBS clients.
As you know, after your login to EBS , OAF pages works through the server side java. When it comes to the Forms screens, and applet is triggered, and client side java starts to service.
Being a client dependent environment, makes the EBS client's to be managed by the Client Support teams That iss , Client side management becomes mandatory..
Plugin, add-on and browser updates should be under control..
Normally, System administrators or Client Support teams are responsible from these kind of management activities, but when a conflict or a problem occurs; unfortuneatly, this duty remains for Apps Dbas and makes their job even harder..
The job is hard because everything gets updated.. You know, Browser vendor updates their security levels, Java becomes more enhanced in security, code fixes or upgrades break the interoperability and so on..
Everything seems documented, but when it comes to real life, even client side management may become an headache.
I already have a blog post regarding EBS Common Client Problems & Solutions..
http://ermanarslan.blogspot.com.tr/2013/07/ebs-common-client-problems-solutions.html
In another post, I have explained the Security enhancements in Java and their effect to EBS clients..
http://ermanarslan.blogspot.com.tr/2014/04/ebs-and-java-7-security-missing.html
Today, I will explain running multiple Java Plugins for Internet Explorer in EBS clients..
The process is complicated.. Fortuneatly, I have a real life experience about it.
The requirement arises, when you have multiple web applications which require different Java plugins..
In this example;
We had EBS 12.2 , which may be connected using Java Plugin 1.6.0_45 , and another web application which must be connected using Java Plugin 1.7.0_51..
Every user had their own PCs, and must be able to work both on EBS and on the other Web Application in their Desktop PCs .
That is , Internet Explorer on a PC should be able to connect and work properly in EBS as well as in another application which requires java 1.7.0_51...
The necessity of being able to connect two different application; have brought an requirement to have two java plugins 1)java plugin 1.6.0_45 and 2)1.7.0_51 coexist in Client's Windows PC.
So far so good.. We might install both of them.. Right?
But what about the decision that IE should make ?
I mean; IE should work properly when the client will choose to connect to EBS and at the same time IE should work properly, even if the client will choose to connect to the other application , which requires java plugin 1.7.0_51..
Note that : The clients browsers were IE 10 32 bit.
First of all, lets answer the following questions:
Does EBS 12.2 work properly in 1.7.0_51? YES
Is the IE - EBS and Java Plugin certified with each other? YES
So why were we afraid?
1.7.0_51 is a high-tech java.. It has new security enhancements, and it will warn the client or it may create problems if the codes/Jars are unsigned..
As you may expect, this environment had unsigned jars in EBS..
I mean the jars were unsigned and there were no near future plans for signing them.
I thought the best approach would be going through the possible scenarios and make a decision to build an action plan after that.
Okay, lets see what we have on our agenda :) ;
1.7.0.51 installed but disabled, 1.6.0.45 installed & enabled :
Even when we have disabled the java plugin 1.7.0.51 and opened the forms we saw that java plugin 1.7.0.51 was trigged ..
Okay, after 1.6.0.45 opened the forms screens, everthing looked normal except one thing.. That is, when we logged out from the forms and tried to open a new form session without logging out from EBS , we had encountered FRM-92050.. On the other hand, the error was seen in the first try, subsequent tries were successful.
When I analyzed the situation , I conclude that this was caused by an EBS bug.. The bug was there for IE 8, but it seemed applicable for IE 10,too.
1.7.0.51 installed & enabled , 1.6.0.45 installed & enabled :
In this scenario, 1.7.0.51 was directly triggered, but this time EBS forms sessions were serviced by the 1.7.0.51, not 1.6.0.45..
So the continuation of the story was the same as above..
Okay, after 1.7.0.51 opened the forms screens, everthing looked normal except one thing.. That is, when we logged out from the forms and tried to open a new form session without logging out from EBS , we had encountered FRM-92050.. On the other hand, the error was seen in the first try, subsequent tries were successful.
When I analyzed the situation , I conclude that this was caused by an EBS bug.. The bug was there for IE 8, but it seemed applicable for IE 10, too
1.7.0.51 installed and 1.6.0.45 installed, and what if we Switch Java Plugins with a registry update?
It was a good idea to switch the java plugin used by IE according to the application needs. Playing with the windows registry ? Okay I had the stomach for that kind of thing :) at least before this experience:)
I mean, if the user want to login to EBS, he/or she may switch the java plugin to 1.6.0.45 using a req file.. Similarly, if the user want to log in to the other application, he/or she may switch the java plugin to 1.7.0.51 using the relevant req file..
First of all, messing with windows registry is not a good thing, it is complicated and complex..
Especially if you have to change the configuration of this kind of tightly integrated programs..
When I worked on the registry I saw that IE and Java plugins are tightly integrated, it is not like throw a flip and everything works as you want them to work.. Java plugin related keys were everywhere in registry, and it was hard to make a point shot..
What I did was,
I first installed 1.6.0.45 and exported the reqistry from the Local Machine > Software
Then I installed 1.7.0.51 and imported the req that I exported before the installation , and it worked ! :)
I mean, with this action, IE started to use 1.6.0.45 even if 1.7.0.51 was installed on the system.
To switch bask to 1.7.0.51 , I made the same but in e opposite way. That is, I imported the req file which was containg the condition of " Local Machine > Software " (the original condition) at the the java plugin 1.7.0.51 was installed..
So when I switched IE to work with 1.6.0.45,,no problems encountered at all.. No security questions regarding the code signing , no forms errors ..
Also, to make the other application work, I switched the IE to work with 1.7.0.51 ..
Anyways.. This approach was working , but it was messy.. Probably unsupported by Microsoft..
Okay, we have seen the scenarios and different approaches above, so what is our conclusion then?
I think the Windows registry update should be considered as a last resort.
The best approach is to apply the patch mentioned above and sign the JARS. The JARS should be signed with a code signing certificate gathered from a CA. If signing JARS are not considered, then the clients should be willing to respond to the security prompts..Nevertheless, the prompt appear only when a new browser session/or lets say new browser tab is opened..
That 's all for now. I hope you find it useful. Feel free to comment..
As you know, after your login to EBS , OAF pages works through the server side java. When it comes to the Forms screens, and applet is triggered, and client side java starts to service.
Being a client dependent environment, makes the EBS client's to be managed by the Client Support teams That iss , Client side management becomes mandatory..
Plugin, add-on and browser updates should be under control..
Normally, System administrators or Client Support teams are responsible from these kind of management activities, but when a conflict or a problem occurs; unfortuneatly, this duty remains for Apps Dbas and makes their job even harder..
The job is hard because everything gets updated.. You know, Browser vendor updates their security levels, Java becomes more enhanced in security, code fixes or upgrades break the interoperability and so on..
Everything seems documented, but when it comes to real life, even client side management may become an headache.
I already have a blog post regarding EBS Common Client Problems & Solutions..
http://ermanarslan.blogspot.com.tr/2013/07/ebs-common-client-problems-solutions.html
In another post, I have explained the Security enhancements in Java and their effect to EBS clients..
http://ermanarslan.blogspot.com.tr/2014/04/ebs-and-java-7-security-missing.html
Today, I will explain running multiple Java Plugins for Internet Explorer in EBS clients..
The process is complicated.. Fortuneatly, I have a real life experience about it.
The requirement arises, when you have multiple web applications which require different Java plugins..
In this example;
We had EBS 12.2 , which may be connected using Java Plugin 1.6.0_45 , and another web application which must be connected using Java Plugin 1.7.0_51..
Every user had their own PCs, and must be able to work both on EBS and on the other Web Application in their Desktop PCs .
That is , Internet Explorer on a PC should be able to connect and work properly in EBS as well as in another application which requires java 1.7.0_51...
The necessity of being able to connect two different application; have brought an requirement to have two java plugins 1)java plugin 1.6.0_45 and 2)1.7.0_51 coexist in Client's Windows PC.
So far so good.. We might install both of them.. Right?
But what about the decision that IE should make ?
I mean; IE should work properly when the client will choose to connect to EBS and at the same time IE should work properly, even if the client will choose to connect to the other application , which requires java plugin 1.7.0_51..
Note that : The clients browsers were IE 10 32 bit.
First of all, lets answer the following questions:
Does EBS 12.2 work properly in 1.7.0_51? YES
Is the IE - EBS and Java Plugin certified with each other? YES
So why were we afraid?
1.7.0_51 is a high-tech java.. It has new security enhancements, and it will warn the client or it may create problems if the codes/Jars are unsigned..
As you may expect, this environment had unsigned jars in EBS..
I mean the jars were unsigned and there were no near future plans for signing them.
I thought the best approach would be going through the possible scenarios and make a decision to build an action plan after that.
Okay, lets see what we have on our agenda :) ;
1.7.0.51 installed but disabled, 1.6.0.45 installed & enabled :
It made the security checks and passed the control to 1.6.0.45..
So the security baseline thing seemed to work :)
| JRE 7 Version | JRE 6 Security Baseline |
|---|---|
| 1.7.0_67 1.7.0_65 | 1.6.0_81 |
| 1.7.0_60 1.7.0_55 | 1.6.0_75 |
| 1.7.0_51 | 1.6.0_71 |
| 1.7.0_45 | 1.6.0_65 |
| 1.7.0_40 1.7.0_25 | 1.6.0_51 |
| 1.7.0_21 | 1.6.0_45 |
While making security checks, it asked to question "Do you want to run this application?", which was an expected one, as it was caused by the security enhancement made in the 1.7.0.51.
The answer could not be cached, and the question was repeated in every new browser session (I mean after closing IE , or opening a new tab -> the question was repeated)
Note that : the question was related with the code signing, as our customer did not not have signed jars..
Okay, after 1.6.0.45 opened the forms screens, everthing looked normal except one thing.. That is, when we logged out from the forms and tried to open a new form session without logging out from EBS , we had encountered FRM-92050.. On the other hand, the error was seen in the first try, subsequent tries were successful.
"FRM-92050 When Re-Opening Forms using Internet Explorer 8 On 12.2.3 (Doc ID 1932415.1)"..
So, the patch referenced in the document should fix the issue..
1.7.0.51 installed & enabled , 1.6.0.45 installed & enabled :
In this scenario, 1.7.0.51 was directly triggered, but this time EBS forms sessions were serviced by the 1.7.0.51, not 1.6.0.45..
So the continuation of the story was the same as above..
While making security checks, it asked to question "Do you want to run this application?", which was an expected one, as it was caused by the security enhancement made in the 1.7.0.51.
The answer could not be cached, and the question was repeated in every new browser session (I mean after closing IE , or opening a new tab, the question was repeated)
Note that : the question was related with the code signing, as our customer does not have signed jars
Okay, after 1.7.0.51 opened the forms screens, everthing looked normal except one thing.. That is, when we logged out from the forms and tried to open a new form session without logging out from EBS , we had encountered FRM-92050.. On the other hand, the error was seen in the first try, subsequent tries were successful.
"FRM-92050 When Re-Opening Forms using Internet Explorer 8 On 12.2.3 (Doc ID 1932415.1)"..
1.7.0.51 uninstalled and 1.6.0.45 installed
No problems at all.. No security questions regarding the code signing , no forms errors ..
But what about the other application that requires 1.7.0.51 right? :) It will not able work properly..
But what about the other application that requires 1.7.0.51 right? :) It will not able work properly..
1.7.0.51 installed and 1.6.0.45 installed, and what if we Switch Java Plugins with a registry update?
It was a good idea to switch the java plugin used by IE according to the application needs. Playing with the windows registry ? Okay I had the stomach for that kind of thing :) at least before this experience:)
I mean, if the user want to login to EBS, he/or she may switch the java plugin to 1.6.0.45 using a req file.. Similarly, if the user want to log in to the other application, he/or she may switch the java plugin to 1.7.0.51 using the relevant req file..
First of all, messing with windows registry is not a good thing, it is complicated and complex..
Especially if you have to change the configuration of this kind of tightly integrated programs..
When I worked on the registry I saw that IE and Java plugins are tightly integrated, it is not like throw a flip and everything works as you want them to work.. Java plugin related keys were everywhere in registry, and it was hard to make a point shot..
What I did was,
I first installed 1.6.0.45 and exported the reqistry from the Local Machine > Software
Then I installed 1.7.0.51 and imported the req that I exported before the installation , and it worked ! :)
I mean, with this action, IE started to use 1.6.0.45 even if 1.7.0.51 was installed on the system.
To switch bask to 1.7.0.51 , I made the same but in e opposite way. That is, I imported the req file which was containg the condition of " Local Machine > Software " (the original condition) at the the java plugin 1.7.0.51 was installed..
So when I switched IE to work with 1.6.0.45,,no problems encountered at all.. No security questions regarding the code signing , no forms errors ..
Also, to make the other application work, I switched the IE to work with 1.7.0.51 ..
I must say that If it could be analyzed further, a point shot could be made.. I mean only the necessary keys in the reqisty could be updated for such a switch operation..
Anyways.. This approach was working , but it was messy.. Probably unsupported by Microsoft..
Okay, we have seen the scenarios and different approaches above, so what is our conclusion then?
I think the Windows registry update should be considered as a last resort.
The best approach is to apply the patch mentioned above and sign the JARS. The JARS should be signed with a code signing certificate gathered from a CA. If signing JARS are not considered, then the clients should be willing to respond to the security prompts..Nevertheless, the prompt appear only when a new browser session/or lets say new browser tab is opened..
That 's all for now. I hope you find it useful. Feel free to comment..
Nice Blog Post !
ReplyDelete