Bug 95337 - Class not found in some strange case
Summary: Class not found in some strange case
Status: RESOLVED UNMAINTAINED
Alias: None
Product: konqueror
Classification: Applications
Component: kjava (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-17 13:38 UTC by Stefan Champailler
Modified: 2012-06-18 19:55 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Champailler 2004-12-17 13:38:21 UTC
Version:            (using KDE KDE 3.3.1)
Installed from:    Debian testing/unstable Packages

KJava throws this :

Error during state 1
Backtrace: 
java.lang.ClassNotFoundException: Class:dexia.gewb.client.localHttpGui.HttpApplet
 at org.kde.kjas.server.KJASAppletClassLoader.findClass(KJASAppletClassLoader.java:248)
 at org.kde.kjas.server.KJASAppletClassLoader.loadClass(KJASAppletClassLoader.java:281)
 at org.kde.kjas.server.KJASAppletStub$RunThread.doState(KJASAppletStub.java:123)
 at org.kde.kjas.server.KJASAppletStub$RunThread.run(KJASAppletStub.java:194)

I use J2SDK 1.4.2_04
In konqi : KIO/Security manager are disabled.

In the control center of the JDK, I have added the jvm arguments :

-cp /usr/share/apps/kjava/kjava.jar:/home/stefan/java/classes

The class that is not found resides in :

/home/stefan/java/classes/dexia/gewb/client/localHttpGui/HttpApplet.class

So it appears everything looks fine.

The classes come from this website :  http://netbanking.dexia.be

(and don't try to get this to work with firefox, it's even worse)

stF
Comment 1 Stefan Champailler 2004-12-17 13:50:51 UTC
I move to j2sdk 1.4.2_06 and it doesn't help.

Now some background info :

this netbanking site is my gateway through my bank.
When first connecting (and from time to time), it downloads a complete set of classes in my home directory (dunno exactly how, but I bet I didn't set any Java policy anywhere to prevent that). I think if one connects there, then the classes will be d/l, however you are.

Now, when the class loader tries to use one of the downloaded classes, it seems to fail.

This banking stuff works under MSIE and the support for Linux is very limited.
Comment 2 Stefan Champailler 2004-12-17 13:56:47 UTC
I also tried to add java arguments in konqueror->configure->Java&Javascript:

-cp /home/stefan/java/classes

but it doesn't work. Moreover, when that value I set is not remembered. That is, if I close the configure windows and the reopen it, my arguments have disappeared !

Is there a way to tell kjava to give debug information so that I can eventually trace what's happening. I already have decompiled but I'd be happier if I didn't have to recompile it with my own debugging code :)

thx, stF
Comment 3 Stefan Champailler 2004-12-17 14:42:49 UTC
moved to JRE 1.5.0, nothing changed...
Comment 4 Sean Parsons 2005-03-19 02:48:23 UTC
I have been having a similar issue with my site when trying to get my page XHTML compliant:
http://www.futurenotfound.com/

The top applet loads perfectly fine, but the second one dies with:
Error during state 1
Backtrace: 
java.lang.ClassNotFoundException: Class: com.futurenotfound.web.FNFApplet
 at org.kde.kjas.server.KJASAppletClassLoader.findClass(KJASAppletClassLoader.java:244)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
 at org.kde.kjas.server.KJASAppletClassLoader.loadClass(KJASAppletClassLoader.java:254)
 at org.kde.kjas.server.KJASAppletStub$RunThread.doState(KJASAppletStub.java:167)
 at org.kde.kjas.server.KJASAppletStub$RunThread.run(KJASAppletStub.java:254)

The only difference between the two is how they are called, they are still calling the same applet.

The first is called using the old style <applet> tags.

The second is called using the XHTML <object> tags.

I've tried all sorts to try and get this to work correctly, but the second one always fails.
Comment 5 Koos Vriezen 2005-03-21 12:31:21 UTC
Sean please explain your similarity or else file a new bug report, thanks.
Also what doesn't work btw. The applets starts, shows a black applet, but only with jdk1.5. JDK1.4 gives an error about not using the contentPane with .add.
Comment 6 Sean Parsons 2005-03-21 20:59:57 UTC
I've fixed the issue I was having, there appears to be some kind of a discrepancy between the W3C documentation for this and how the XHTML version actually works in both Konq and Firefox.  I'm gonna do a bit more research to find out and will log a separate bug if necessary.
Comment 7 Ralf Hildebrandt 2005-08-07 13:53:46 UTC
I also tried that: Upon the first visit, konqueror/java download a huge assload of classes (5.5MB!). When one is done with that, one needs to restart the browser. When goin to the same URL, no downloading happens, instead the applet is finally started. Shortly after that, java throws a Class not found exception, although the classes ARE stored locally!!
Comment 8 Koos Vriezen 2005-08-17 00:02:43 UTC
The classpath is already set by the kjava plugin, I don't think adding a -cp does add it. Might be an idea to parse the extra commandline args and extend this classpath. (Your best bet is to make a symlink in KDEDIR/share/kjava/ to your classes I think)
IIRC however, the classpath given by commandline is seen by the jvm as system classpath. Meaning that there is no access restriction whatsoever.
It is possible though to extend the classloader's search path of the applet. But how should this work, ie. how can an applet tell that it needs an extended classpath?
Comment 9 J Appel 2006-09-12 13:37:45 UTC
I can reproduce the bug at http://netbanking.dexia.be with kde 3.5.4

i dl'ed the 5 megs of java classes, the site tells you to restart the browser. after this, i get an "applet failed". -> confirming the bug.
Comment 10 Myriam Schweingruber 2012-06-18 19:55:33 UTC
Message from the Bugsquad and Konqueror teams:
This bug is closed as outdated, as we do not have the manpower to maintain the KDE3 version anymore.
If you still can reproduce this issue with Konqueror 4.8.4 or later, please open a new report.
Thank you for your understanding.