Applet+jar+form?

I got a java search engine jar file. the boss ask me to write a applet to take user input (search keywords) in a html page and feed the input into that jar then output the search result on that page.
how can that be done? I mean it sounds to me like to implement a applet form in html and pass the user input to jar and get out put from jar file and display them.
does anyone have any idea about this?
Thank you in advance.

Wait. Search engine jar file? A more likely scenario is that jar is used to implement a search engine in a servlet environment. On the client side there'd just be web forms. So applets wouldn't enter into it at all. (You could have an applet that acted as a web form, but that would be extraneous.)
Now, maybe someone created a client-side search engine...but this seems counter-intuitive. The important part with a search is the data. You're searching against data of some kind; without the context of the data a search makes little sense. So if it's a client-side search....the question then is what is it exactly that you're searching. Just words on the current page?
A lot of information is missing here.

Similar Messages

Fonts are not reflecting while running Java Applet Through Forms

Hello Oralce Gurus!!
I have a Java Applet which has few lines of text in different
fonts such as AgencyFB, Verdana Ref etc., When I am running this
applet from console, I am able to see the text in different
fonts. Where as If I run the applet through forms (as a Bean
(ViewerBean) ), the fonts are not reflected. The text appears in
a default font.
All the fonts are installed on WinNT, where the applet resides.
I will be greatful if anyone can suggest me a solution.
Thanks,
Raghu

try out this
ImageIcon img1=new ImageIcon(this.getClass().getResource(imagename));
for exmaple
Imageicon img1=new ImageIcon(this.getClass().getResource("name1.jpg"));
dont 4get to include the image files in the jar file

My Applet Jar file doesn't work !!

hello ,
I have written this java applet :
import java.awt.*;
import javax.swing.*;
import java.applet.Applet;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.net.URL;
public class test4 extends Applet implements ActionListener{
     private static final long serialVersionUID = 1L;
     private JButton B1 =new JButton("Forward ");
     private JButton B2 =new JButton("Backward");
     private JButton B3 =new JButton("Left");
     private JButton B4 =new JButton("Right");
private JPanel P1 = new JPanel();
private JPanel P2 = new JPanel();
private JPanel P3 = new JPanel();
private JPanel P4 = new JPanel();
private JPanel P5 = new JPanel();
private JPanel P6 = new JPanel();
private JLabel L3 = new JLabel(" ");
private JLabel L4 = new JLabel(" ");
private JLabel L5 = new JLabel(" ");
private JLabel L6 = new JLabel(" ");
private JLabel L7 = new JLabel(" ");
JSplitPane sppSplitPane0 = new JSplitPane( );
     public test4()
          JFrame.setDefaultLookAndFeelDecorated(true);
          sppSplitPane0.setDividerLocation( 250 );
          P3.add(L4);
          P3.add(B1);
          P3.add(L5);
          P5.add(B3);
          P5.add(L3);
          P5.add(B4);
          P4.add(L6);
          P4.add(B2);
P4.add(L7);
          P1.setLayout(new BorderLayout());
          P1.add("North",P3);
          P1.add("Center",P5);
          P1.add("South",P4);
          P2.setLayout(new BorderLayout());
          P2.add("North" , P1);
          B1.addActionListener(this);
          B2.addActionListener(this);
          B3.addActionListener(this);
          B4.addActionListener(this);
          sppSplitPane0.setLeftComponent(P2);
          sppSplitPane0.setRightComponent(P6);
     public void actionPerformed(ActionEvent e) {
          try {
               if (e.getSource() == B4) {
          URL myNewURL = new URL("http://amera/cgi-bin/test.cgi?R");
          System.out.println("URL = " + myNewURL);
          getAppletContext().showDocument(myNewURL,"blank");
               else
                    if (e.getSource() == B3) {
                    URL myNewURL = new URL("http://amera/cgi-bin/test.cgi?L");
                    System.out.println("URL = " + myNewURL);
                    getAppletContext().showDocument(myNewURL,"blank");
                    else
                         if (e.getSource() == B2) {
                         URL myNewURL = new URL("http://amera/cgi-bin/test.cgi?B");
                         System.out.println("URL = " + myNewURL);
                         getAppletContext().showDocument(myNewURL,"blank");
                         else {
                              URL myNewURL = new URL("http://amera/cgi-bin/test.cgi?F");
                              System.out.println("URL = " + myNewURL);
                         getAppletContext().showDocument(myNewURL,"blank");
          } catch (Exception err) {
          System.err.println("Error!\n" + err);
          showStatus("Error, look in Java Console for details!");
     public static void main(String[] args) {
          test t=new test();
          JFrame frame =new JFrame();
          frame.add(t.sppSplitPane0);
          frame.setSize(1100,700);
          frame.setVisible(true);
i made a jar file :
i created a file and named it MANIFEST.MF .i wrote inside it :
Main-Class: test
Then i placed it in a folder with the test.class .I created jar file using command line.
I entered the test.class path and then wrote this command :
jar cvfm myjar.jar MANIFEST.MF *.class
Then the jar file "myjar.jar" is created .
it's executed but this function "public void actionPerformed(ActionEvent e) " won't wrok.
i keep pressing the buttons but nothing is happening !!
please help me .
Edited by: Amera on Dec 27, 2009 2:51 PM

Welcome to the Sun forums.
Subject: My Applet Jar file doesn't work !! .
1) Note that one '!' denotes exclamation, whereas 2 or more often denotes a dweeb.
2) Since you are on your first post, I will point out that applets are an advanced topic, and should not be attempted by newbies.
3) "doesn't work" is very vague. It is likely to produce a reply like "maybe the applet is lazy - try flogging it".
Amera wrote:
..I have written this java applet :When posting code, code snippets, HTML/XML or input/output, please use the code tags. The code tags help retain the formatting and indentation of the sample. To use the code tags, select the sample and click the CODE button.
Also note that the most preferred form of code is an SSCCE *(<- link).* In an SSCCE, your would remove all but one button (if the actionPerformed fails with 6 or 7 buttons, trim it down to fail with just one or two.
i made a jar file :So does the applet work before you make the Jar file? Your post so far suggests the Jar file is the problem.
i created a file and named it MANIFEST.MF .i wrote inside it :
Main-Class: test
Then i placed it in a folder with the test.class .I created jar file using command line.
I entered the test.class path and then wrote this command :
jar cvfm myjar.jar MANIFEST.MF *.class
Then the jar file "myjar.jar" is created .
it's executed but this function "public void actionPerformed(ActionEvent e) " won't wrok.
i keep pressing the buttons but nothing is happening !!So you get 'no output in the console & no effect in the applet'?
What is the URL where I can see your applet failing?
As an aside, since Sun does not guarantee that applet clients will act on the showDocument command, even if it does not work, it would not be a 'bug'.
Edited by: AndrewThompson64 on Dec 28, 2009 11:18 AM

BigIP F5 : changing IP leads to cache invalidated and redownload of applet jars

Hello all,
In short, I'm trying to figure out how to have the java 7 plugin not considering the server IP to decide whether to use cached version of our applet's signed jars.
As suggested in the title, we use BigIP's F5 boxes to dispatch requests among actual servers, which are located in 2 different sites (disaster recovery purposes).
Each site has an F5 box ; and our DNS resolve the application's host name by alternating between 2 different IPs : one for site 1, the other for site 2.
Each time a user visits http://theapp.mycompany.com, the host is resolved as 9.9.9.1 or 9.9.9.2, more or less randomly.
This works very nicely as long as the applet is not concerned, or bandwith and latency is good enough to absorb 1.5Mb in a snap.
For remote subsidiaries (10.000km away from servers), downloading 1.5Mb takes 35s -- too much for the normal user to wait.
And the problem is : the plugin insists on looking up the server IP each time it starts up, and ignores cache entries that have been downloaded from a different IP.
Here is the use case :
- user connects to http://theapp.mycompany.com ; the browser get an IP, doesn't matter which ; user logs on, navigates in the app's html pages -- no problem
- user gets to the applet :
- the html page says
<applet id="myApplet">
    <param name="archive" value="a.jar,b.jar,c.jar,d.jar,e.jar"/>
    <param name="codebase_lookup" value="false"/>
    <param name="archive_1" value="a.jar, preload, version=7.5.7" />
    <param name="archive_2" value="b.jar, preload, version=7.5.7" />
    <param name="archive_3" value="c.jar, preload, version=7.5.7" />
    <param name="archive_4" value="d.jar, preload, version=7.5.7" />
    <param name="archive_5" value="e.jar, preload, version=7.5.7" />
    <param name="baseUrl" value="/"/>
    <param name="code" value="a/package/for/Applet.class"/>
    <param name="mayscript" value="mayscript"/>
    <param name="codebase" value="/applet/"/>
    <param name="name" value="MyApplet" />"
    <param name="locale" value="fr"/>
</applet>
     The archive_n parameters are here in an attempt to tell the plugin to not even ask for jars if its cache contains entries with same host/same name/same version.
     The version is assigned at build time at an application level ; it has nothing to do with the Implementation-Version attribute found in MANIFEST.MF files.
- Java and the plugin sarts up : let's assume this is the first time : cache is empty : all jars are downloaded ; as they are signed and the CA certificate chain was set in the browser config, and the java.policy is also configured to allow smooth exec, the applet runs smoothly -- after a long startup delay
- user leaves the applet, do some stuff in other applet-less pages for some minutes (the java/plugin processes are shut down after a minute or so)
- user reenters the page that contains the applet
- Java and the plugin start up again :
     - the cache has entries for each jar : host, name, version are all ok.
     - But : the jars are not seen as "prevalidated" ; heres' the applet log ( in French, translation provided after "//") :
network: Vérification de version pour a.jar. La version spécifiée est 7.5.7     //Checking version for a.jar. Specified version is 7.5.7
security: La vérification de révocation de la liste noire est activée     // Check of blacklist revocation is activated
security: blacklist: created: NEED_LOAD, lastModified: 1378474147992
security: blacklist: hasBeenModifiedSince 1380806409906 (we have 1378474147992)
security: La vérification de liste de bibliothèques sécurisées est activée     // Check of trusted libraries is activated
..... same for the other jars ....
network: Created version ID: 7.5.7
network: Created version ID: 7.5.7
network: Entrée de cache trouvée [URL : http://theapp.mycompany.com/applet/a.jar, version : 7.5.7] prevalidated=false/0 //Cache entry found
cache: Adding MemoryCache entry: http://sandbox-mosaic.jcdecaux.com/applet/plannerApplet_7.5.7.jar
network: Created version ID: 7.5.7
     - The plugin then tries to lookup the host IP to check whether it matches that seen when creating the entry
     - 2 possibilities here :
               - the IP returned is the same : the plugin is happy, uses the cached jar, no question/download to/from the server, and the applet starts up quick and runs ok
               - the IP returned is not the same ; the plugin says :
network: Vérification de version pour a.jar. La version spécifiée est 7.5.7     //Checking version for a.jar. Specified version is 7.5.
security: blacklist: created: NEED_LOAD, lastModified: 1378474147992
security: blacklist: hasBeenModifiedSince 1380806409906 (we have 1378474147992)
security: La vérification de liste de bibliothèques sécurisées est activée     // Check of trusted libraries is activated
cache: CacheEntry IP mismatch: 9.9.9.1 != 9.9.9.2
          and then it downloads again the jar.
          Of course, all the jars are treated the same way.
          Note that the applet eventually runs normally ; the only problem is that the cache essentially doesn't work, causing terribly annoying 35s delays at applet startup.
Interestingly enough, examining the jdk 6 code shows that the "prevalidated=false" fragment (in bold/pink above) means that the method CacheEntry.isKnownToBeSigned() returns false.
I tried with a self-signed certificate which I added first in IE as "Trusted publisher" ; I also tried with a certificate signed by a CA that is known by IE -- no help.
So I really wonder : what does it take to have the plugin consider that each jar "isKnownToBeSigned" ?
Any thoughts ?
Note : we of course are considering packing jars, cleaning dead code, etc. to decrease applet size. But it doesn't help with the fact that the plugin considers the IP, which it shouldn't do in our case. And even with pack200 we're left with +350Kb of unnecessary downloads, not counting with future code to be developped ...
Thanks for any feedback
David
Browser is IE7.
Complete dump of system properties :
__applet_launched = 280874909499
__jvm_launched = 280874910680
acl.read = +
acl.read.default =
acl.write = +
acl.write.default =
awt.toolkit = sun.awt.windows.WToolkit
browser = sun.plugin
browser.vendor = Oracle
browser.version = 1.1
file.encoding = Cp1252
file.encoding.pkg = sun.io
file.separator = \
file.separator.applet = true
http.agent = Mozilla/4.0 (Windows Vista 6.0)
http.auth.serializeRequests = true
https.protocols = TLSv1,SSLv3
java.awt.graphicsenv = sun.awt.Win32GraphicsEnvironment
java.awt.printerjob = sun.awt.windows.WPrinterJob
java.class.path = C:\tools\Java\jre7\classes
java.class.version = 51.0
java.class.version.applet = true
java.endorsed.dirs = C:\tools\Java\jre7\lib\endorsed
java.ext.dirs = C:\tools\Java\jre7\lib\ext;C:\Windows\Sun\Java\lib\ext
java.home = C:\tools\Java\jre7
java.io.tmpdir = C:\Users\taille\AppData\Local\Temp\
java.library.path = C:\tools\Java\jre7\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Program Files\Internet Explorer;;C:\oracle\ORA102\bin;C:\Perl\site\bin;C:\Perl\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;c:\Program Files\Common Files\Roxio Shared\DLLShared\;C:\Program Files\JavaSoft\JRE\1.3.1_06\bin;C:\ORACLE\Ora92\jre\1.3.1\bin;C:\ORACLE\Ora92\jre\1.1.8\bin;C:\tools\Groovy-1.7.5\bin;C:\tools\Graphviz2.28\bin;C:\tools\Git\cmd;C:\tools\tortoiseSVN\bin;C:\Program Files\Windows Imaging\;C:\oracle\ORA102\bin;C:\Perl\site\bin;C:\Perl\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;c:\Program Files\Common Files\Roxio Shared\DLLShared\;C:\Program Files\JavaSoft\JRE\1.3.1_06\bin;C:\ORACLE\Ora92\jre\1.3.1\bin;C:\ORACLE\Ora92\jre\1.1.8\bin;C:\tools\Groovy-1.7.5\bin;C:\tools\Graphviz2.28\bin;C:\tools\Git\cmd;C:\tools\tortoiseSVN\bin;C:\Program Files\Windows Imaging\;.
java.protocol.handler.pkgs = sun.plugin.net.protocol|com.sun.deploy.net.protocol
java.rmi.server.RMIClassLoaderSpi = sun.plugin2.applet.JNLP2RMIClassLoaderSpi
java.runtime.name = Java(TM) SE Runtime Environment
java.runtime.version = 1.7.0_21-b11
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
java.specification.version = 1.7
java.vendor = Oracle Corporation
java.vendor.applet = true
java.vendor.url = http://java.oracle.com/
java.vendor.url.applet = true
java.vendor.url.bug = http://bugreport.sun.com/bugreport/
java.version = 1.7.0_21
java.version.applet = true
java.vm.info = mixed mode, sharing
java.vm.name = Java HotSpot(TM) Client VM
java.vm.specification.name = Java Virtual Machine Specification
java.vm.specification.vendor = Oracle Corporation
java.vm.specification.version = 1.7
java.vm.vendor = Oracle Corporation
java.vm.version = 23.21-b01
javaplugin.nodotversion = 10212
javaplugin.version = 10.21.2.11
javaplugin.vm.options = -Ddeployment.trace.level=all -Duser.language=en
javawebstart.version = javaws-10.21.2.11
line.separator = \r\n
line.separator.applet = true
mrj.version.applet = true
os.arch = x86
os.arch.applet = true
os.name = Windows Vista
os.name.applet = true
os.version = 6.0
os.version.applet = true
package.restrict.access.com.sun.deploy = true
package.restrict.access.netscape = false
package.restrict.access.org.mozilla.jss = true
package.restrict.access.sun = true
package.restrict.definition.com.sun.deploy = true
package.restrict.definition.java = true
package.restrict.definition.netscape = true
package.restrict.definition.org.mozilla.jss = true
package.restrict.definition.sun = true
path.separator = ;
path.separator.applet = true
sun.arch.data.model = 32
sun.awt.enableExtraMouseButtons = true
sun.awt.warmup = true
sun.boot.class.path = C:\tools\Java\jre7\lib\resources.jar;C:\tools\Java\jre7\lib\rt.jar;C:\tools\Java\jre7\lib\sunrsasign.jar;C:\tools\Java\jre7\lib\jsse.jar;C:\tools\Java\jre7\lib\jce.jar;C:\tools\Java\jre7\lib\charsets.jar;C:\tools\Java\jre7\lib\jfr.jar;C:\tools\Java\jre7\classes;C:\tools\Java\jre7\lib\deploy.jar;C:\tools\Java\jre7\lib\javaws.jar;C:\tools\Java\jre7\lib\plugin.jar
sun.boot.library.path = C:\tools\Java\jre7\bin
sun.cpu.endian = little
sun.cpu.isalist = pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
sun.desktop = windows
sun.io.unicode.encoding = UnicodeLittle
sun.java.command = sun.plugin2.main.client.PluginMain write_pipe_name=jpi2_pid7004_pipe37,read_pipe_name=jpi2_pid7004_pipe36
sun.java.launcher = SUN_STANDARD
sun.jnu.encoding = Cp1252
sun.management.compiler = HotSpot Client Compiler
sun.net.client.defaultConnectTimeout = 120000
sun.net.http.errorstream.enableBuffering = true
sun.os.patch.level = Service Pack 2
trustProxy = true
user.country = FR
user.dir = C:\dtaille\TMA\perfs_br\newcert
user.home = C:\Users\taille
user.language = fr
user.name = taille
user.script =
user.timezone = Europe/Paris
user.variant =
Vider les propriétés de déploiement...
active.deployment.proxy.bypass.local = false
active.deployment.proxy.same = false
active.deployment.proxy.type = 3
deployment.baseline.url = https://javadl-esd-secure.oracle.com/update/baseline.version
deployment.blacklist.url = https://javadl-esd-secure.oracle.com/update/blacklist
deployment.blacklisted.certs.url = https://javadl-esd-secure.oracle.com/update/blacklisted.certs
deployment.browser.path = C:\Program Files\Mozilla Firefox\firefox.exe
deployment.browser.vm.iexplorer = true
deployment.browser.vm.mozilla = true
deployment.cache.enabled = true
deployment.cache.jarcompression = 0
deployment.cache.max.size = 726
deployment.capture.mime.types = false
deployment.console.startup.mode = SHOW
deployment.control.panel.log = false
deployment.expiration.decision.10.21.2 = later
deployment.expiration.decision.suppression.10.21.2 = true
deployment.expiration.decision.timestamp.10.21.2 = 9/6/2013 15:29:3
deployment.insecure.jres = PROMPT
deployment.javafx.mode.enabled = true
deployment.javapi.cache.update = false
deployment.javapi.lifecycle.exception = false
deployment.javapi.log.filename =
deployment.javapi.runtime.type = 0
deployment.javapi.stop.timeout = 200
deployment.javapi.trace.filename =
deployment.javaws.appicon.index = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\appIcon\appIcon.xml
deployment.javaws.associations = ASK_USER
deployment.javaws.cache.update = false
deployment.javaws.concurrentDownloads = 4
deployment.javaws.install = IF_HINT
deployment.javaws.installURL = http://java.sun.com/products/autodl/j2se
deployment.javaws.logFileName =
deployment.javaws.muffin.max = 256
deployment.javaws.shortcut = ASK_IF_HINTED
deployment.javaws.splash.index = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\splash\splash.xml
deployment.javaws.traceFileName =
deployment.javaws.uninstall.shortcut = false
deployment.javaws.update.timeout = 1500
deployment.javaws.viewer.bounds = 1723,197,881,546
deployment.jpi.mode.new = true
deployment.log = false
deployment.macosx.check.update = true
deployment.max.output.file.size = 10
deployment.max.output.files = 5
deployment.mime.types.use.default = true
deployment.modified.timestamp = 1380804178316
deployment.proxy.bypass.local = false
deployment.proxy.override.hosts =
deployment.proxy.same = false
deployment.proxy.type = 3
deployment.security.SSLv2Hello = false
deployment.security.SSLv3 = true
deployment.security.TLSv1 = true
deployment.security.TLSv1.1 = false
deployment.security.TLSv1.2 = false
deployment.security.askgrantdialog.notinca = true
deployment.security.askgrantdialog.show = true
deployment.security.authenticator = true
deployment.security.blacklist.check = true
deployment.security.browser.keystore.use = true
deployment.security.clientauth.keystore.auto = true
deployment.security.disable = false
deployment.security.https.warning.show = false
deployment.security.jsse.hostmismatch.warning = true
deployment.security.level = HIGH
deployment.security.local.applets = PROMPT
deployment.security.mixcode = DISABLE
deployment.security.notinca.warning = true
deployment.security.password.cache = true
deployment.security.run.untrusted = PROMPT
deployment.security.sandbox.awtwarningwindow = true
deployment.security.sandbox.casigned = PROMPT
deployment.security.sandbox.jnlp.enhanced = true
deployment.security.sandbox.selfsigned = PROMPT
deployment.security.trusted.policy =
deployment.security.validation.crl = false
deployment.security.validation.ocsp = false
deployment.security.validation.ocsp.publisher = false
deployment.system.cachedir = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\SystemCache
deployment.system.security.blacklist = C:\tools\Java\jre7\lib\security\blacklist
deployment.system.security.cacerts = C:\tools\Java\jre7\lib\security\cacerts
deployment.system.security.jssecacerts = C:\tools\Java\jre7\lib\security\jssecacerts
deployment.system.security.oldcacerts = C:\tools\Java\jre7\lib\security\cacerts
deployment.system.security.oldjssecacerts = C:\tools\Java\jre7\lib\security\jssecacerts
deployment.system.security.trusted.certs = C:\tools\Java\jre7\lib\security\trusted.certs
deployment.system.security.trusted.clientauthcerts = C:\tools\Java\jre7\lib\security\trusted.clientcerts
deployment.system.security.trusted.jssecerts = C:\tools\Java\jre7\lib\security\trusted.jssecerts
deployment.system.security.trusted.libraries = C:\tools\Java\jre7\lib\security\trusted.libraries
deployment.system.tray.icon = true
deployment.trace = true
deployment.update.mime.types = true
deployment.user.cachedir = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\cache
deployment.user.extdir = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\ext
deployment.user.logdir = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\log
deployment.user.security.blacklist = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\blacklist
deployment.user.security.blacklist.dynamic = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\blacklist.dynamic
deployment.user.security.blacklisted.certs = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\blacklisted.certs
deployment.user.security.policy = file:/C:/Users/taille/AppData/LocalLow/Sun/Java/Deployment/security/java.policy
deployment.user.security.sandbox.certs = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\sandbox.certs
deployment.user.security.saved.credentials = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\auth.dat
deployment.user.security.trusted.cacerts = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.cacerts
deployment.user.security.trusted.certs = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs
deployment.user.security.trusted.clientauthcerts = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.clientcerts
deployment.user.security.trusted.jssecacerts = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.jssecacerts
deployment.user.security.trusted.jssecerts = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.jssecerts
deployment.user.security.trusted.libraries = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.libraries
deployment.user.tmp = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\tmp
deployment.version = 7.21
deployment.webjava.enabled = true
java.quick.starter = false

This behavior was introduced by a security "fix" intended to prevent a DNS re-binding attack which permits unsigned applets to escape the applet sandbox. The "fix" was, imo, very poorly thought out. You think you have a problem with 1.5 megabits of applet jars, but I have 8 megabytes, hundreds of thousands of users, with lousy networks. So now I'm stuck with a colocation vendor. Imagine my chagrin when they changed *their* ISP and thus their IP addresses.
As far as I can see, signed applets are already permitted (if the user allows) to communicate outside the sandbox, so this "fix" should not have been applied to signed jars, only to unsigned ones. There are a couple of other techniques that Oracle might have used to prevent this attack, but they chose the simplest one, effectively preventing anyone from using the most common, inexpensive strategies for improving the availability of their web-based Java applications.

Cannot perform Bean lookup on signed Applet jar

Hi All,
I'm after developing an applet which runs from a number of jars on an Orion app server. Each one of these jars are signed and I can access the Applet okay. The problem is that I make remote reference to EJB's throughout the application. I cannot perform a Bean lookup on a signed jar. The only way it can be done is when the Client is granted all permissions. The client should pop up an option to grant permissions.

If u are signing all the jar file along with the applet it should work
It does work fine with me. my code given below
note that i carry the following jar files along with my applet jar.
orion.jar,ejb.jar,,jta.jar,jnet.jar,jsse.jar,jcert.jar,parser.jar
and have them in my archive attribute of my html code for the applet
also all these jars are signed
hope this helps
regards
raees
public void init()
     try
          Hashtable env = new Hashtable();
          env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
          env.put(Context.PROVIDER_URL, "ormi://solomon:23791/helloApp");
          env.put("java.naming.security.principal", "admin");
          env.put("java.naming.security.credentials", "secret");
          Context ic = new InitialContext (env);
          HelloHome hello_home = (HelloHome)ic.lookup("HelloBean");
     Hello hello = hello_home.create ();
          System.out.println (hello.helloWorld ());
     }catch(Exception e)
          e.printStackTrace();

How to load an applet jar file?

Hello everyone,
I have an applet that uses my own jar file and approximately 6 third party jar files. I set up jar indexing (jar -i) which will download the jar files when they are needed. All seems to work well, but now I want to manually load the jar files which I cannot get working.
When the applet starts, about 1/2 of the jar files are downloaded (because they are needed at startup). I then want to load the additional jar files in the background, after the gui is initialized. I have tried this using the below thread which is executed from within the applet's start method:
// Try to load additional jar files in background by loading a class from each jar file.
Thread loadClass = new Thread() {
public void run() {
    System.out.println("Loading classes...");
    try {
      // Tried loading classes this way, doesn't work.
      getClass().getClassLoader().loadClass("pkg1.Class1");
      getClass().getClassLoader().loadClass("pkg2.Class2");
      getClass().getClassLoader().loadClass("pkg3.Class4");
      getClass().getClassLoader().loadClass("pkg4.Class4");
      /* Loading classes this way doesn't work either.
      Class.forName("pkg1.Class1");
      Class.forName("pkg2.Class2");
      Class.forName("pkg3.Class3");
      Class.forName("pkg4.Class4");
    catch(ClassNotFoundException e) {
      // First attempt to load a class (pkg1.Class1) throws exception.
      System.out.println("Can't find class: " + e.getMessage());
loadClass.start();As you can see from above I am trying to load a class from each of the jar files so that the jar files would load into memory/cache. Unfortunately, it cannot find the classes. These are the errors from the java console:
Loading classes...
Loading: pkg1.Class1
Connecting http://my.server.com/my_dir/pkg1/Class1.class with no proxy
Connecting http://my.server.com/my_dir/pkg1/Class1.class with cookie "JSESSIONID=some_big_long_char_list"
Can't find class: pkg1.Class1
So it appears the jar file is not being downloaded. When I take away the dynamic jar loading (removing the "jar -i" & adding them all to the applet archive list) the thread executes correctly. So I know the class names, etc, are correct. How does one load an applet jar file?
Any help/suggestions are appreciated.

The above error I posted was because I forgot to index the jar files. That is why it couldn't find the jar file. I thought I was getting farther along with my problem, but I apparently just forgot to index the jars. I am now getting the problem that I got yesterday...
The applet freezes/hangs when it hits the thread. The GUI never opens (even though I'm running this thread right after the gui shows). The java console quits responding and the applet just stays the grey screen. I also tried the invoke later that you suggested.
public void start() {
// ...initialize gui...
// Applet freezes and remains grey, also the java console freezes.
javax.swing.SwingUtilities.invokeLater(new Runnable() {
    public void run() {
      System.out.println("Loading classes...");
      try {
        // When I comment out the below forName calls, the thread will still run evidenced through the done print statement.
        Class.forName("pkg1.Class1");
     Class.forName("pkg2.Class2");
     Class.forName("pkg3.Class3");
     Class.forName("pkg4.Class4");
        System.out.println("...Done loading classes");
      catch(Exception e)     {
        System.out.println("Can't find class: " + e.getMessage());
}

Question about Java Applet Jar file signing.

These questions pertain to Java 6 Standard Edition 1.6.0_22-b04 and later.
I have gone through the Oracle Java Tutorial for generate public and private key information
to sign a jar file, and how to sign the jar itself, all at
[http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html|http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html]
, and seek some clarification on the following related questions:
-In order to "escape" the java applet sandbox that exists around the client's
copy of the applet running in their web browser, ie.
(something forbidden by default), is verification of the signed applet enough, or is a policy file required
to stipulate these details?
-using the policytool policy file generator, what do I need to add under "Principals"
(if anything) when dealing with a Java applet? Are Codebase and SignedBy simply author information?
-If I choose to use a java.security.Permission subclass object set up in equivalent fashion within the Applet,
which class within the Applet jar do I instantiate that object in? Does it need to be mentioned
in the applet's jar Manifest.MF file?
-Is the "keystore database" a java language service/process which runs in
the Server's memory and is simply accessed and started by default
by the client verifier program (appletview/web browser)?
-The public key certificate file (*.cer) is put in the webserver directory holding
the Applet jar file (ie. Apache Tomcat, for example).
-Presumably, the web browser detects the signed jar
and certificate file, and provides the browser pop up menu asking the user
about a new, non recognised certificate (initially).
Is this so?
-With this being the case, can the applet now escape
the sandbox, be it with or without the stipulated
policy permissions?

848439 wrote:
-In order to "escape" the java applet sandbox that exists around the client's
copy of the applet running in their web browser, ie.
(something forbidden by default), is verification of the signed applet enough, or is a policy file required
to stipulate these details?Just sign the applet, the policy file is not necessary.
-Is the "keystore database" a java language service/process which runs in
the Server's memory and is simply accessed and started by default
by the client verifier program (appletview/web browser)?No.
-The public key certificate file (*.cer) is put in the webserver directory holding
the Applet jar file (ie. Apache Tomcat, for example).No. For a signed Jar, all the information is contained inside the Jar.
-Presumably, the web browser detects the signed jar
and certificate file, and provides the browser pop up menu asking the user
about a new, non recognised certificate (initially).
Is this so?No. It is the JVM that determines when to pop the confirmation dialog.
-With this being the case, can the applet now escape
the sandbox, ..Assuming the end-user OK's the trust prompt, yes.
..be it with or without the stipulated
policy permissions?Huh?

Loading images inside applet JAR

Hi
This is my issue: I have an applet which contains images inside the applet JAR. I want to display these images in my applet, but apparently due to browser access restrictions, I'm not allowed.
My first code was like this:
//security restrictions on browsers do not allow getResource
ImageIO.read(MyClass.class.getResource("imgs/img.png"));
//getResourceAsStream should be allowed by browsers
ImageIO.read(MyClass.class.getResourceAsStream("imgs/img.png"));Both lines work when I execute the applet locally (command line / programming IDE), but when I deploy it to my web server, the resource "imgs/img.png" becomes a relative URL to my web application context (like /webcontext/MyClass/imgs/img.png). It works locally because the call to getResource returns a URL object with "file:" protocol, but I need it to look for my images bundled inside the JAR, not web hosted images.
I need to avoid making the applet look for these images as a web resource... how can I do it?
Thanks!

dev@java wrote:
warnerja wrote:
I'm not convinced the code you posted wouldn't work, but since this is an applet, you have access to the Applet class. Check out the Applet.getImage method in conjunction with Applet.getCodeBase.
[http://java.sun.com/javase/6/docs/api/java/applet/Applet.html]
getCodeBase returns my web context, like http://myhost.com/mycontext/ , so it is pretty much the same as above.
Thanks for your replyThat is the way to load resources though. Hence back to my earlier statement about not being convinced it would not work, with this addition: It should work, assuming you actually do have the resources properly located with the web app, whether they be in a jar, or loose files relative to where the web app is. My guess at this point is that they are not.

Where is the Applet JAR file?

When an Applet (the JAR) is downloaded to the local PC, exactly where (the directory) we can locate the Applet JAR file? Is the file managed by the Internet browser?

This has got to be browser-specific.
You shouldn't write code that depends on this kind of information anyway.

Applet jar creation

I am creating a web application, and the server side objects are fairly simple to create with the NDS.
Now I want to create some applets and create the JAR for deployment within my web application. To add, the applet passes objects back and fourth to the server, so my web application will need to be aware of the classes in the applet application.
How do I do this within NDS?

hi nathan,
first thing add your applet jar file in the java build path of your project.
while accessing the method at runtime of these jar file pass the required objects.
regards,
guru

Certificate inquiry for changes in applet jar

Hi everybody,
I have an applet that uses a certificate to allow saving of file to local disk. I downloaded the certificate and imported in the keystore and cacerts using keytool.
However, there are cases we need to change the applet. I updated the jar file with the revised version of applet.
My question is: Do I need to change the certificate and perform again the importing to keystore and cacerts to point the the revised applet so that I could save a file to local disk?
My concern is that what if many users have already performed the certificate importing, do they need to do again the procedure of importing certificate.
Your comments are very appreciated.
Thanks!
vamendoza

You should only need to re-sign the applet jar with the same certificate.

Using a java applet as form

hi there,
I'm new to programming applets (but not new to java and gui programming).
Here's my question:
I would like to use a java applet with a textfield as form input. is this possible?
I see some several advantages over using standard html textfields and java script. (f.e.: I can set the cursor to any position after changing the text in the field).
I'm thinking on a solution by my own. Would it be possible to use a java script method to access a property from the applet? so I could use a combination of java applet, html and java script. On the onClick() event I read the actual value from the applet and do some normal post request. Any better suggestions?
thx
soa

I want to write the textfield in java. So I use the applet as form.
What would be your suggestion?
Write an applet with an textfield and and getValue() method? So I could create a normal html button and use javascript to write a method wich acces this getmethod. So I could register this method to the onClick() event.

Cipher.getInstance closes Applet JAR file.

I am trying to use a Cipher in a signed Applet in java plugin-1.4 under I.E. Once I execute a Cipher.getInstance the applet jar file is closed and I cannot create any new classes that havent been previously loaded from it. The classloader ends up returning an "IlleagleStateException: Zip file closed".
Is this a known bug? Is there a workaround? Perhaps a way to re-open the JAR file.
I have been combing the FAQ's without finding any other refrences to the problem.

I haven't found a solution to the original problem but for someone else that is looking for a workaround for this. I found that if I use two JAR with my Cipher in the second one, I can still load class files out of the first. I.E. <PARAM NAME = java_archive VALUE = "supportClasses.jar,mainApplet.jar"> where mainApplet.jar contains the code that uses the Cipher.

Applet oracle/forms/fnd/formsclient/formslauncher started

Hi All,
DB:11.1.0.7
Oracle Apps: 12.1.1
O/S: Red Hat Linux
One of the users is receiving the message - 'applet oracle/forms/fnd/formsclient/formslauncher started' and thereafter no further progress while launching form.
Could anyone please share what the issue is and hwo to solve it.
Thanks for your time!
Regards,

Should jinitiator be uninstalled and re-installed again for the client pc?Do you mean Sun JRE? If yes, then yes you could do -- Recommended Browsers for Oracle E-Business Suite Release 12 [ID 389422.1]
Also, try the same from the same machine using a different browser and see if you can reproduce the issue.
Thanks,
Hussein

Slow download of large applet jars - please help!

We have a large applet (7 meg plus several meg more
in 3rd party libraries) which take too long to download
under slow connections (e.g. wireless VPNs). We cannot
depend on browser/java-plugin cache to speed things up
because users clear caches often. Our market will not consider
an "installed application" as an alternative. There is now a political
effort where I work to throw out lots of excellent Java technology
because of this.
Here is what I need:
* Break our code into several smaller jars and initially
download just one small applet jar that logs a user into
our service.
* Treat all the rest of the jars as portions of a "plug-in", which
is downloaded after that, as needed, and installed on the client
machine outside of browser/plugin cache.
* The main small applet code would "install the plugin" as needed
and call into these installed jar files to do all the rest of it's work
* The jars that are part of this "plug-in" would have their own smart
update mechanism so only the portions changed in a new release
need to be downloaded - implemented apart from the Java plugin
cache.
Yes, the plugin concept is largely user perception, but in our market
it is unavoidable. If the first small piece loads and runs quicker, then
the installation of a "plugin" after that may be more tolerable. And the
downloaded components won't get lost by clearing caches.
If anyone has ideas on how to do this, please help. Otherwise a lot
of really good Java technology will go down the drain for largely
political reasons. I need a good technical solution for this.
Thanks,
/Mark

Another point: we need the first small jar file to download
and start running without the other jar files. The other jar files
need to then be downloaded on-demand and/or in the background
with good user feedback (e.g. progress bar) - giving the perception
to the user of "components of a plug-in" being installed. So we'd
need to invent some deferred-fetching stuff.
What users really don't like is waiting a long time for EVERYTHING
to download and nothing has actually started to run. It doesn't seem
like the Java plug-in alone will get us to that point.
/Mark

Applet+jar+form?

Similar Messages

Maybe you are looking for