Applet ServerSocket SecurityException

SecurityExceptionEx[Host]: cannot access 11110
My applet is signed.
I use netscape security:
PrivilegeManager.enablePrivilege("UniversalConnect");
PrivilegeManager.enablePrivilege("UniversalListen");
PrivilegeManager.enablePrivilege("UniversalAccept");
but no use because there is an SecurityException.
Please tell me how can I solve this problem.

Be carefull if you acces the web through a proxy server, that may be a problem 4 the cnx.
Hope to be helpfull, make me know if not
...where Java has never gone before

Similar Messages

Xalan applet getProperty securityException

If I use xalan2.2D6 for xsl transformation in an applet I get the following securityException:
Is ther a proper way to solve this problem ?
I hacked TreeWalker.java and removed the getProperty calls. It works for me but I'm shure its not the best way
to do it.
Regards Christian
java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read)
     at java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
     at java.security.AccessController.checkPermission(AccessController.java:399)
     at java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
     at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1278)
     at java.lang.System.getProperty(System.java:560)
     at org.apache.xml.utils.TreeWalker.<init>(TreeWalker.java:149)
     at org.apache.xml.dtm.ref.dom2dtm.DOM2DTM.<init>(DOM2DTM.java:1563)
     at org.apache.xml.dtm.ref.DTMManagerDefault.getDTM(DTMManagerDefault.java:185)
     at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:585)
     at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1037)

I have the same problem.
Does anybody know elegant solution for this problem ?
Please...
Sincerely,
Victor Letunovsky
AlarIT programmer
http://www.AlarIT.com

Report in Applet throws SecurityException

Hello,
I try to integrate CrystalReport into my Applet.
ReportClientDocument reportClientDoc = new ReportClientDocument();
reportClientDoc.open("reportName.rpt", 0);
ReportViewerBean reportViewer = new ReportViewerBean();
reportViewer.setReportSource(reportClientDoc.getReportSource());
reportViewer.init();
reportViewer.start();
The Applet throws a SecurityException. It runs if the java.policy from client will be modified:
grant {
permission java.util.PropertyPermission "*", "read,write";
permission java.io.FilePermission "<<ALL FILES>>", "read, write, delete, execute";
permission java.lang.RuntimePermission "createClassLoader";
Is there a way without a modify by client? Server can be adjust.
Edited by: ergerg on Aug 17, 2011 8:29 PM

here it is :
java.security.AccessControlException: access denied (java.io.FilePermission lena.png read)
     at java.security.AccessControlContext.checkPermission(AccessControlContext.java:270)
     at java.security.AccessController.checkPermission(AccessController.java:401)
     at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
     at java.lang.SecurityManager.checkRead(SecurityManager.java:887)
     at sun.awt.SunToolkit.getImageFromHash(SunToolkit.java:408)
     at sun.awt.SunToolkit.getImage(SunToolkit.java:422)
     at javax.swing.ImageIcon.<init>(ImageIcon.java:81)
     at javax.swing.ImageIcon.<init>(ImageIcon.java:107)
     at PNGLoader$1.actionPerformed(PNGLoader.java:38)
     at java.awt.Button.processActionEvent(Button.java:381)
     at java.awt.Button.processEvent(Button.java:350)
     at java.awt.Component.dispatchEventImpl(Component.java:3526)
     at java.awt.Component.dispatchEvent(Component.java:3367)
     at java.awt.EventQueue.dispatchEvent(EventQueue.java:445)
     at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:190)
     at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:144)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:130)
     at java.awt.EventDispatchThread.run(EventDispatchThread.java:98)

Signed applet throws SecurityException

I have trouble with java applets and access permissions (plugin 1.3.0_02).
Although I signed the applet using a Verisign certificate
and although the user grants access (when loading the
applet a security dialog pops asking for permission),
the applet obviously does not have "AllPermission"
code:
    String host = "abc"
    int port = 80
    // the following code throws a SecurityException
    Socket = new Socket(host, port);from java console:
java.security.AccessControlException: access denied (java.net.SocketPermission abc resolve)
why is that so ?
what's wrong here ?
this is how I created the jar:
- compile applet to my.class file
- generated jar: jar cvf my.jar mydir
- sign the jar: jarsigner -keystore mykeystore my.jar mycertificate (mykeystore contains the "mycertivicate" Verisign certificate)
at least something works since the plugin 1.3.0_02 detects the certificate and pops up the security dialog asking the user for access permissions.
the documentation says (see http://java.sun.com/products/plugin/1.3/docs/nsobjsigning.html#deploy), that when the user "grants always" the applet gets "AllPermission".
but the applet obviously does not get "AllPermission"
however, the code will work when I manually add "AllPermission" on the client side using the policytool. but it is not accetable solution to have client users use
policytool for granting permissions...
please help!!!

I found the problem: the critical code was in a second jar file having a different code base (org.abc.... instead of de.abc...). So I only had to sign the additional jar file and then it worked...
...

Using XMLEncoder in Applet causes securityexception

I've written a simple Applet which should be able to XMLEncode a bean and write the XML-code to the standard output. (later it should be expanded to place various beans on a panel and write the XML to the server the applet is placed on, to be able to retrieve it later for further editing, but which is not the point right now)
The problem is when I run it in Internet Explorer or Netscape with Java plug-in 1.4.01, I get 9 times the following security exception before I get the output.
My question is, is there some way to prevent this security exception from occuring?
java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
Continuing ...
<?xml version="1.0" encoding="UTF-8"?>
<java version="1.4.0" class="java.beans.XMLDecoder">
<object class="javax.swing.JButton">
<void property="actionCommand">
<string>Hello, world</string>
</void>
<void property="label">
<string>Hello, world</string>
</void>
<void property="model">
<void property="actionCommand">
<null/>
</void>
</void>
</object>
</java>
I've got this simple code:
public class XMLTest extends javax.swing.JApplet {
public XMLTest() {
public void init() {
java.beans.XMLEncoder xmle = new java.beans.XMLEncoder(System.out);
xmle.writeObject(new javax.swing.JButton("Hello, world"));
xmle.close();
<HTML>
<HEAD>
<TITLE>Applet HTML Page</title>
</head>
<BODY>
<APPLET code="XMLTest.class" width=200 height=100>
</applet>
</body>
</html>

Thanks for the info; if it's really the last opportunity, I'll sign it, but it's not the intention at all to step out of the sandbox. The Applet doesn't need to write to the local file-system, all what it needs to do is read out the parameters of the beans it contains with XMLEncoder and put it in a string so I can send to the server it came from (this is no security issue).
The output XMLEncoder produces after the security exceptions (see the first message) is sufficient, contains enough parameters and can be used well the reverse way with XMLDecoder and without any security exceptions.
My question is this: Is XMLEncoder itself using code which bypasses the sandbox (probably yes) and is there some way to influence the process of encoding so the security exceptions don't occur?

Applet : caught a SecurityException. That's OK.

I am trying to connect a Stateless Session Bean from an Applet. Do I
need to add any permissions in the weblogic.policy files or to the JRE
policy files used by the browser?
Without providing any extra permissions anywhere, I am able to set the
InitialContext and lookup the EJBHome object using the initial
context.but when i am casting the object looked up to the corresponding
EJB home object using PortableRemoteObject.narrow(), I am getting the
exception(a snapshot):
caught a SecurityException. That's OK.
looked up.............:javax.naming.InitialContext@4d1d41
looked up.............:ClusterableRemoteRef(192.9.126.107
[192.9.126.107])/285
Interface 0:
com.mindteck.spider.uaa.server.slbean.UAAUserAuthenticatorHome
Interface 1: javax.ejb.EJBHome
Interface 2: weblogic.ejb20.interfaces.RemoteHome
Interface 3: weblogic.rmi.internal.StubInfoIntf
before casting
java.lang.ClassCastException
at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(Unknown
Source)
at javax.rmi.PortableRemoteObject.narrow(Unknown Source)
at
com.mindteck.spider.uaa.client.ui.UAAUserLogin.btnAuthenticate_actionPerformed(UAAUserLogin.java:203)

Hi Cameron,
Thanks for your reply but the problem is if I grant all permission to the JRE
policy file used by the browser then the stuff is working coolly.
Can you suggest alternative way to receive asynchronous messages(JMS) by the
applet which has been processed and added to the Queue by an EJB.
Thanks
Sanjit
Cameron Purdy wrote:
Generally speaking, Applet to EJB direct connection is a very bad approach.
Are you sure that is what you should do?
Peace,
Cameron Purdy
Tangosol, Inc.
Clustering Weblogic? You're either using Coherence, or you should be!
Download a Tangosol Coherence eval today at http://www.tangosol.com/
"Sanjit Bose" <[email protected]> wrote in message
news:[email protected]..
I am trying to connect a Stateless Session Bean from an Applet. Do I
need to add any permissions in the weblogic.policy files or to the JRE
policy files used by the browser?
Without providing any extra permissions anywhere, I am able to set the
InitialContext and lookup the EJBHome object using the initial
context.but when i am casting the object looked up to the corresponding
EJB home object using PortableRemoteObject.narrow(), I am getting the
exception(a snapshot):
caught a SecurityException. That's OK.
looked up.............:javax.naming.InitialContext@4d1d41
looked up.............:ClusterableRemoteRef(192.9.126.107
[192.9.126.107])/285
Interface 0:
com.mindteck.spider.uaa.server.slbean.UAAUserAuthenticatorHome
Interface 1: javax.ejb.EJBHome
Interface 2: weblogic.ejb20.interfaces.RemoteHome
Interface 3: weblogic.rmi.internal.StubInfoIntf
before casting
java.lang.ClassCastException
at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(Unknown
Source)
at javax.rmi.PortableRemoteObject.narrow(Unknown Source)
at
com.mindteck.spider.uaa.client.ui.UAAUserLogin.btnAuthenticate_actionPerform
ed(UAAUserLogin.java:203)

ServerSocket can't see Applet

I must be missing something obvious here. My ServerSocket sits
waiting for a connection but the Applet (on the same machine)
never requests a connection. See the Server and Client below...
The applet comes up fine and tries to connect. The server never
gets the request. Is there something else I need to do???
Client Applet:
ProxyAddr = InetAddress.getLocalHost();
try {
aSocket = new Socket(ProxyAddr , 4400);
out = new PrintWriter(aSocket.getOutputStream(), true);
in = new BufferedReader(new InputStreamReader(aSocket.getInputStream()));
} catch (UnknownHostException e)
Applet1.decThreads();
System.err.println("Don't know about host: "+host+lineSep);
Applet1.callbackData(lineSep+"Couldn't find host "+host, ip, host);
return;
} catch (IOException e)
Applet1.decThreads();
System.err.println("Couldn't get I/O for the connection .");
Applet1.callbackData(lineSep+"failed to get I/O for the connection"+lineSep, ip, host);
return;
Server:
serverSocket = new ServerSocket(4400);
if (debug)
System.out.println("Starting to listen...");
     while (listening)
               new AppletProxyThread(serverSocket.accept()).start();
     serverSocket.close();
Thanks for helping.

I am running the server on a unix machine. Could this be the
problem? What should I use? I thought that maybe I should
be getting the address by passing the path to some api
like "getLocalIP("/home/myid/my_html/theServer") or something like it.
There's so much on the web but I need an example that works.
I've tried just using new socket("127.0.0.1", portNum); but this
doesn't work, also tried the aforementioned 'getLocalHost' and
tried new socket("www.mydomain.com", portNum);, Also doesn't
work.
The real path is /home/myuserid/my_html/myServer.jar... I am
confused. It of course works when I run the server on my Windows machine
using JBuilder.

SecurityException: Unable to create temporary file with applet

My applet tries to write a temp file
try {
          File temp = java.io.File.createTempFile("student", ".log");
          strFilename = temp.getAbsolutePath();
} catch (IOException e1) {
          e1.printStackTrace();
}But when I run, it throws an exception:
java.lang.SecurityException: Unable to create temporary file
I tried to sign the applet, as to http://www.developer.com/java/data/article.php/3303561 but it's still the same.
There's another way: using java.policy,
grant {
permission java.security.AllPermission;
};but it seems to be not very gentle. Could you show me the solution please? Thanks in advance.
Cheers,

Yes, that's what I found. Here is the summary to do it, hope it helps someone else:
1. Create key for signed jar:
keytool -genkey -keystore abc.com -keyalg rsa -dname "CN=Abc, OU=Def, O=GHI, L=KLMN, ST=OP, C=XY" -alias TheCert -validity 3600 -keypass password -storepass password2. Make jar file
3. Sign the jar file
jarsigner -keystore abc.com -storepass password -keypass password -signedjar SignedAppletTest.jar OrgAppletTest.jar TheCertIt works for me.
I'd like to thank harmmeijer and everyone who interests.
Cheers,

TCP server applet, can't instance ServerSocket

Hy guys ! i'm havin trouble getting my server applet on it's feet, this is mainly because it won't get past instancing the server socket.
this is the code i'm using, i've put it in a button's event handler
        String clientSentence;
        try{
        System.out.println("starting Server");
        ServerSocket welcomeSocket = new ServerSocket(6789);
        while (true) {
            Socket connectionSocket = welcomeSocket.accept();
            System.out.println("Server has started");
            BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream()));
            DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());
            clientSentence = inFromClient.readLine();
        }catch(Exception e){
        System.out.println("there's a problem :"+e.getMessage());}i run the applet, click the button, i see "starting Server", and it locks up. I've tried other ports, no difference it locks up on any port

OK, let's forget the applet now. Your application should work. "Does not get that far". How far does it get?
A debugger should tell you. Or some System.out.println() placed all over the place. It's hard to see what happens with so little info. I strongly believe that it gets farther than this. It gets to the accept() call and it blocks there, as it should. Let it run to wherever it goes, open a Command Prompt and type "netstat -an". I believe your server should be listed something like this:
TCP    0.0.0.0:6789            0.0.0.0:0              LISTENINGIf it is, the application works fine.
Check the code with correct System.out.println():
package testcuc;
import java.io.*;
import java.net.*;
public class Main {
    public static void main(String[] args) {
        String clientSentence;
        String capitalizedSentence;
        try{
        System.out.println("starting Server");
        ServerSocket welcomeSocket = new ServerSocket(6789);
        System.out.println("Server has started");
        while (true) {
            System.out.println("Waiting for client to connect");
            Socket connectionSocket = welcomeSocket.accept();
            System.out.println("Client connected");
            BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream()));
            DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());
            clientSentence = inFromClient.readLine();
            capitalizedSentence =clientSentence.toUpperCase() + '\n';
            outToClient.writeBytes(capitalizedSentence);
        }catch(Exception e){
        e.printStackTrace();}
    }//main
}//MainEdited by: baftos on May 18, 2009 2:47 PM

One-off SecurityException loading applet

We have a signed applet that has been executed in production about 1400 times. Today during a test we got this:
java.lang.SecurityException: trusted loader attempted to load sandboxed resource from http://verismart.everforge.com:8080/vContent/vsim/telnet/jta26.jar
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1400(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)Never seen this before and cannot reproduce. We tried about 25 times. Nothing has changed that we are aware of. Any clues?
Java 1.6 at both ends, not sure of versions, not too recent anyway.

Thanks but it's not mixed code. Everything is signed, and has been for months. And none of those dialogs appeared.

Advice needed: New Applet to talk to ServerSocket

Hi,
I have to write this from scratch, so please feel free to re-direct me in a whole new direction. Here's what I have to do:
1. We generate some real time information (numerical) which I have to display to my clients in an applet in grid format (tabular)
2. The data changes maybe 4-5 times a minute and the client applets should pick up these changes and display them with no more than 10-15 second delay.
3. I already have a serversocket application which can send this information over TCP/IP sockets. Applets can make socket connections and readLine() from here.
4. The number of applets simultaneously accessing this data could be 1000 or more.
5. I am comfortable doing the server side development but am very weak as far as writing applets.
Questions:
1. How should I go about writing the applet to display the dynamically changing information?
2. How can I hide the port number where the applet connects - i.e. prevent the port number from being revealed via a decompiler?
3. How can I make it very difficult for someone to first download and then decompile my JAR file? I have seen sites that use "CABBASE" and keep code in CAB files. Can I package my class files in the CAB files instead of JAR files? Will it help?
4. What else can I do to keep unauthorized entities from accessing the real time raw feed from my serversocket app?
Thanks!

4. The number of applets simultaneously accessing
this data could be 1000 or more.You should probably set up more than one server to distribute the load of all these clients
1. How should I go about writing the applet to
display the dynamically changing information? 1. Initiate your applet
2. Register your connection with the backend data provider
3. Have a thread listen for updates, then update your applet
2. How can I hide the port number where the applet
connects - i.e. prevent the port number from being
revealed via a decompiler?It's a little tricky. I believe the guys who created Mocha also SELL software for making java classes undecompilable.
How useful would your applet code be without the backend data? Would anyone really be interested in trying to redistribute it maliciously?
Honestly, your first line of defense should be to try to set up some sort of connection filter, where either your clients have to log in before getting to your applet, or the backend ServerSocket (or whatever) checks to make sure the IP of the incoming request is authorized.
3. How can I make it very difficult for someone to
first download and then decompile my JAR file? I have
seen sites that use "CABBASE" and keep code in CAB
files. Can I package my class files in the CAB files
instead of JAR files? Will it help?I doubt it. CAB is just about the same thing as a jar.
4. What else can I do to keep unauthorized entities
from accessing the real time raw feed from my
serversocket app?
Thanks!

Java.awt.createFont(...) in Applet

I'm trying to dynamically load a truetype-font in an applet with Font.createFont(...) .
Unfortunately I'm always getting
java.lang.SecurityException: Unable to create temporary fileAnd, surprise, surprise, Font.createFont() requires a temporary file wich I found not to be documented in javadoc but in the source of Font.java (see last line of the next code example):
public static Font createFont ( int fontFormat, InputStream fontStream )
      throws java.awt.FontFormatException, java.io.IOException {
      if ( fontFormat != Font.TRUETYPE_FONT ) {
          throw new IllegalArgumentException ( "font format not recognized" );
      File fontFile = null;
      fontFile = File.createTempFile ( "font", ".ttf", null );Has anybody faced the same problem or an idea of how to solve this issue with little additional work?

has really nobody got an idea?

Problem with Image I/O and applet

I am having trouble using Image I/O to load a PNG image in an applet. I am just using a very basic applet that simply loads the image from a URL and that's it, and the exception I get is -
java.lang.SecurityException: Unable to create temporary file
at java.io.File.checkAndCreate(File.java:1294)
at java.io.File.createTempFile(File.java:1385)
The simple applet is as follows -
import java.awt.image.*;
import java.net.*;
import java.io.*;
import javax.swing.*;
import javax.imageio.ImageIO;
public class CheckImageApplet extends JApplet
public BufferedImage bi = null;
public void init()
URL url = null;
BufferedImage bi = null;
try
url = new URL( "http://localhost/CheckImageSystem/checkimages/backGS.png" );
catch ( MalformedURLException mfue )
try
bi = ImageIO.read( url );
catch ( IOException ioe )
Any thoughts on this exception would be appreciated

It seems the line
bi = ImageIO.read( url );
fails. Can't see anything else. Perhaps this method needs to create a temp image for some reason, and tries to do this at the local harddrive (not allowed). Use getImage(URL, String); instead. ImageIO isn't intended for applets, I think, so you should use the applet methods.
Nille

Can't run JRE 1.2.2 applets once 1.4.1 installed

I have an applet developed with JDK 1.2.2 (uses 3rd-party jars) which was working perfectly with the 1.2.2 plug-in
that comes with the JDK.
The OBJECT tag specifies the dynamic versioning clsid clsid:8AD9C840-044E-11D1-B3E9-00805F499D93 (which is the
only possibility for 1.2.2?).
However, when users who have downloaded the 1.4.1 plug-in run the applet (quite apart from the fact that I have had
to solve a problem where plug-in 1.2.2 accepts PARAMs with initail _ but plug-in 1.4.1 does not!) they are
getting an ExceptionInInitializerError inside one of the 3rd-party libraries. I have reproduced this
error on my Windows XP PC (IE 6). The stack trace is as follows :
(this has been reproduced outside of the browser using JRE 1.4.1 because the 1.4.1 plug-in console won't display,
even after manually running the Console and setting the Show Console checkbox,
and the icon doesn't appear on the System menu, presumably all because I have JDK 1.2.2 + plug-in installed)
java.lang.ExceptionInInitializerError
at javax.crypto.Mac.getInstance(DashoA6275)
at com.baltimore.jpkiplus.pkcs12.PFX.fromASN1Object([DashoPro-V1.3-01300
0])
at com.baltimore.jpkiplus.pkcs12.PFX.fromBER([DashoPro-V1.3-013000])
at com.baltimore.jpkiplus.pkcs12.PFX.<init>([DashoPro-V1.3-013000])
at com.baltimore.jpkiplus.pkidevice.PKCS12Provider.openFile([DashoPro-V1
.3-013000])
at com.baltimore.jpkiplus.pkidevice.PKCS12Provider.openFile([DashoPro-V1
.3-013000])
at com.baltimore.jpkiplus.pkidevice.PKCS12Device.initInstance([DashoPro-
V1.3-013000])
at com.baltimore.jpkiplus.pkidevice.PKIDeviceManager.getPKIDevice([Dasho
Pro-V1.3-013000])
at com.baltimore.jpkiplus.vaults.Vault.a([DashoPro-V1.3-013000])
at com.baltimore.jpkiplus.vaults.Vault.openVault([DashoPro-V1.3-013000])
at mailsign.signer.signAndSend(signer.java:262)
at mailsign.AppletSigner.signAndSend(AppletSigner.java:329)
at mailsign.AppletSigner.action(AppletSigner.java:521)
at java.awt.Component.handleEvent(Unknown Source)
at java.awt.Component.postEvent(Unknown Source)
at java.awt.Component.postEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
at javax.crypto.SunJCE_b.<clinit>(DashoA6275)
... 24 more
Caused by: java.lang.UnsupportedOperationException
at java.security.cert.CertificateFactorySpi.engineGenerateCertPath(Unkno
wn Source)
at java.security.cert.CertificateFactory.generateCertPath(Unknown Source
at javax.crypto.SunJCE_d.a(DashoA6275)
at javax.crypto.SunJCE_d.a(DashoA6275)
at javax.crypto.SunJCE_b.i(DashoA6275)
at javax.crypto.SunJCE_b.h(DashoA6275)
at javax.crypto.SunJCE_v.run(DashoA6275)
at java.security.AccessController.doPrivileged(Native Method)
... 25 more
In my opinion, this has something to do with the way service providers are handled. The 3rd party jar requires
a Security.insertProviderAt () call. My suspicion is that there is some kind of conflict with the JCE stuff
that comes bundled with JRE 1.4.1 to handle RSA signed applets. I found a similar conflict with the 1.2.2 JRE
when I tried to jarsign the 3rd-party libraries - I was getting, at runtime, either some kind of infinite loop hanging or
a stack overflow due to recursive function calls.
The fact that I can run the applet as a main and that I get the exact same error running the app from the DOS
prompt would indicate that this is a JRE 1.4.1 problem (surely the JREs are supposed to be downwardly-
compatible??!!! - i.e. the JRE 1.4 should run apps compiled with JDK 1.2.2 without any problem). Yes, I have
run the app as a main with JRE 1.2.2 and all works fine.
However, I could get around this if I could force the 1.2.2 plug-in to run instead of the 1.4.1 plug-in (quite
how the users are going to be able to get the 1.2.2 plug-in if they have plug-in 1.4.1 installed
without being Java experts is a problem I will leave
till later when I try to figure out how to make my applet an RSA signed applet (which if the documentation is
correct are only available from 1.3 onwards, hence solving this 1.4.1 problem would be VERY nice)).
But the problem is that once the 1.4.1 plug-in is installed, it always takes precedence over lower versions.
It's not obvious from the documentation whether older plug-in versions get executed when static versioning
is used for the clsid in the OBJECT tag. I can't be bothered to download a 1.3 plug-in and try.
However, unless I am mistaken, there is not a static versioning clsid for plug-in 1.2.2 ?????
In summary, once users download a plug-in version greater than 1.2.2 (presumably by running another applet from some
other site that requires eg 1.4.1 - I guess Sun's aim is to make the Plug-In as prevalent as possible, hence
this is not a far-fetched scenario), it is no longer possible for my applet to be run by a 1.2.2 JRE !!!!!!!
Because the 1.4.1 JRE is not downwardly-compatible, it can't run my 1.2.2-developed applet and my deployed
application is broke.
Unless I am missing something somewhere (which is possible because I am getting fed up of solving problem after
problem with the Plug-In - eg the mess of setting the right codebase to get different plug-ins to be downloaded
automatically - the HTML converter doesn't always set up the codebase correctly), this seems like a nightmare
for applet developers - from one day to the next your applications will break because of Sun's plug-in upgrading.
Please tell me there is a way to force the 1.2.2 JRE/plug-in to execute instead of 1.4.1 and that there is a
way for the 1.2.2 plug-in to be downloaded automatically by users even when they have 1.4.1 already installed.

Are you using signtool? I had a problem where applets stopped working when I went from JRE 1.3.1_01a to 1.3.1_07. I updated the signtool from 1.1 to 1.3 and now my applets run.
Mark

Socket communication failure between Java applet and C++ application

I have a java applet that connects to a C++ application via Java's ServerSocket and Socket objects. THe C++ application is using the Winsock 2 API. The applet and application are running on an NT workstation (SP 6) and using IE (5.5) For a very simple C++ test applications the communictions work fine. Once more code gets added to the C++ application the portion of the socket that C++ listens to seems to close. Upon performing a recv call the return value is a zero. Microsoft insists this is a sign the Java side has shut down the socket. The Java applet can still receive messages from the C++ app but C++ cannot receive responses from the Java side. Java throws no exceptions and an explicit check of the socket shows no errors. Again, what puzzles me is that it works for simple C++ applications. Are there any known conflicts between Java and C++ in this regard?
I have inlcuded the basic java code segments below.
/ run Method.
* This method is called by the Thread.start() method. This
* method is required for the implementation of the Runnable interface
* This method sets up the server side socket communication and
* contiuously loops looking for requests from a external
* socket.
* @author Chris Duke
public void run(){
     // create socket connections
     boolean success = false;
     try {
         cServerSocket = new ServerSocket(cPortID);
         System.out.println("Waiting for client to connect...");
         cClientSocket = cServerSocket.accept();
         System.out.println("Client connected");
         // Create a stream to read from the client
         cInStream = new BufferedReader(new InputStreamReader(
           cClientSocket.getInputStream()));
         // Create a stream to write to the client
         cOutStream = new PrintWriter(
           cClientSocket.getOutputStream(), true);
         success = true;
     }catch (IOException e) {
         System.out.println("CommSocket:Run - Socket Exception(1) " + e);
         success = false;
     // if the socket was successfully created, keep the thread running
     while (success){
         try{
            // check socket to see if it is still available for reading
            if (cInStream != null && cInStream.ready()){
                // check for an incoming message
                String message = ReceiveMessage();
                // Send message to listeners
                Event(message);
            if (cInStream == null){
                success = false;
                System.out.println("CommSocket:Run - shutdown");
         }catch (IOException e){
            System.out.println("CommSocket:Run - Socket not ready exception");
            break;
// SendMessage method -
* Sends a text message to a connected listener through port specified by portID
* @author Chris Duke
* @param String message - This will be the message sent out through the server
* socket's port specified by portID.
   public void SendMessage(String message){
      cOutStream.println(message);
      if (cOutStream.checkError() == true)
        System.out.println("SendMessage : Flush = Error");
      else{
        System.out.println("SendMessage : Flush - No Error");
   }

a very simple C++ test applications the communictions work fine. Once more code gets added to the C++ application the portion of the socket that C++ listens to seems to close.
This quite strongly implicates the extra code in the C++ App. The firstly thing I would try would be telnet. Try connecting to both versions of the C++ Application and manually reproducing a proper exchange.
a recv call the return value is a zero. Microsoft insists this is a sign the Java side has shut down the socket.
A correct implementation of recv should return the number of bytes received, or -1 for an error. A zero return indicates no bytes received not a socket closed/error. This sounds like FUD to me.
Are there any known conflicts between Java and C++ in this regard?
I can see no obvious faults, though the code is incomplete, I don't think it's an sockets implementation issue, at either end, it sounds more likely to be a protocol/handshaking bug in the C++ App.

Applet ServerSocket SecurityException

Similar Messages

Maybe you are looking for