I'm testing a web page with an applet in it which should connect to a MySQL database.
There is an error and I get this in the Java console :
What annoys me very much, is the last line of this error message :"5 more". I would really like to see what these 5 more lines are. Maybe the solution to my problem is there. So, my question is : is there any way to configure or manipulate the java console to actually see the whole error message ?
I don't know what will be there, that's kind of my point. I would really like to know what's there and i'm not as sure as you are that it will not help me. If you consider the first message, the lines locating the error in my app are the last 2 lines, so it may be not that irrelevant.
Let me jump you over your doubts by telling you that unsigned applets can't do a number of things that signed applets can. So when you get that AccessControlException in an applet, it's because you are doing a prohibited action. The error message does tell you what action that is, but the solution is to sign the applet.
Joined: Mar 21, 2011
Thanks for the answer, but i think i have to expand the context a little bit. There is a (working) existing old application which runs on an old dying server and is mainly composed of a big applet and some jsp under a Tomcat 5.0 server. This applet connects to an old huge database(750 MB) which runs on a MySQL 4.0 server. I didn't write the application, i didn't even get the sources; i had to decompile them from the .class files. The guy who did write the thing is long gone and i have to migrate the whole stuff on a virtual server, equipped with a MySQL 5.5 and a Tomcat 5.5 (which i cannot change). I first migrated the database with a dump, i had to erase all the "Type = MyIsam" in the dump file, but otherwise it did get well, i can access and request it from MySQL Workbench without any problem. I then tried to install the app on the Tomcat, the web page and applet are working up to the point where the applet tries to connect to the database and i get the aforementioned error message on the console.
If possible, i want to avoid meddling with the decompiled java code (i don't have a proper project , just a bunch of decompiled java files). As the applet is working on the old server, i reckon it should be working on the new one without changing anything in the code, i use the decompiled files only to check how the applet connects to the database and it seems to get connection information from the web.xml file in the tomcat app directory. I updated these informations for the new server, but it didn't work, i also changed the jdbc connector and put a newer one and i get the previously evoked error message.
So, i don't know if signing the applet would change that, after all it worked as such on the old server. But i really would like to read the error lines the console deprives me of. Mabe it won't help me, but at least i would know
Well, I'm sorry, but I don't know how to change the Java configuration in your browser to produce full stack traces. But nevertheless you do need a signed applet to do what you want to do. Most likely the old version of the applet was signed, but now that you've recompiled a new version of the applet, you're going to need to sign that too.
Joined: Mar 21, 2011
In fact, i did not recompile the applet. I copied the .class files from the old to the new server, so i guess if it was signed on the old server it's still signed now, and if it wasn't, well it worked without.
Anyways, thanks for your time and your answers, i'll try to figure it out and if i don't, well i'll rewrite the Applet (at least parts of it)
Were the old class files inside a jar file (or zip file?) Signing an applet involves putting it in a jar file with special entries in the manifest. If you unpacked the jar, you "unsigned" the applet.
As far as the missing lines: the last missing line would be something in com.mysql.jdbc.NonRegisteringDriver.connect() . That method called something, which called something (three more times) which asked for something in com.mysql.jdbc.StringUtils, which tried to load that class, which failed to initialize because, basically, it won't work in an unsigned applet. That failure threw an exception which was uncaught for a few stack frames, and then was eventually caught in NonRegisteringDriver.connect() . That's it -- the missing stuff really isn't going to tell you anything.