no nie do końca.
One of the most important part of this Applet are these two lines:
String myServer = this.getCodeBase().getHost ();
jndiProps.setProperty("java.naming.provider.url", myServer ) ;
We make sure that we access the server from which we have just been downloaded. Attempt to access another server would raise a security exception.
Warning
you need to access your HTML page from the hostname or IP address to which the EJB server is bound! For the sandbox, 192.168.1.1 and 127.0.0.1 are two different hosts even if in reality they represent the same host.
Consequently, if you access your web page through http://127.0.0.1/TestApplet.html and, in your code, attempt to reach your EJB at IP 192.168.1.1, an exception will be raised.
Un-trusted Applets are very sensitive to their environment! For example, imagine you access your web page through the 127.0.0.1 IP address. The Applet will use this address when performing the lookup on the JNDI tree to get the home proxy. This will work. But you have no control on:
*
The codebase address used by the RMI subsystem on the server to allow dynamic code downloading
*
The RMI target that the proxy holds
In consequence, as soon as the first EJB invocation will be fired or as soon as the client will need to dynamically load code from the server, it will use the address specified on the server i.e. 192.168.1.1 and a security exception will be raised.
sprawdź jak się łączysz. Możliwe że z rozpędu coś piszesz ie tak jak bozia przykazała.
Dwa to na końcu jest napisane, że łatwiej jest podpisać aplet niż użerać się z kontekstami.
Trzy, kilka jarów w jednym aplecie:
<PARAM NAME = ARCHIVE VALUE = "AppletClient.jar, jboss-client.jar, jboss-j2ee.jar, jbosssx-client.jar,
jnp-client.jar, jndi.jar, jaas.jar" >
Rozdzielasz po przecinku adresy URL.