I've built an applet (from JApplet) that consumes several other jar files. I've signed my jar that contains the main class and included all of the jars I need (I think). However, no matter what I try, I consistently get "java.lang.ClassNotFoundException: newposting" where 'newposting' is the main class within my signed jar. I'm using the following html for this:
<p><applet code="newposting"
archive="HartfordRowingNewPosting.jar,
javax.mail.jar,
jcalendar-1.4.jar,
junit-4.6.jar,
jgoodies-common-1.2.0.jar,
jgoodies-looks-2.4.1.jar,
mysql-connector-java-5.1.25-bin.jar"
width="500" height="850">
<param name="permissions" value="sandbox" />
<param name="codebase" value="HartfordRowingNewPosting.jar" />
</applet></p>
The jars and html are all located in the same folder on the server. I've tried several combinations of path specifications. I've also tried using jnlp but get the same error. I've been frustrated with this on and off for the last month or so. Can someone shed some light on this?
The fact the ClassNotFoundException is thrown when loading your main class means that either your class cannot be read from jar or your jar cannot be found.
I hope that your verified that your clas is indeed in jar. If not try it. Just to be sure try to use unsigned jar and see that you have exactly the same error.
If so you still have 2 possibilities.
Are you sure that your class is indeed called newposting? Lowercase? In default package? Note: this must be fully qualified class name.
Next, test that your jar is indeed available for browser. To do so just copy and paste the jar name to browser prepending it with your URL. For example if HTML is available under http://myhost/myapp/mypage.html try URL http://myhost/myapp/HartfordRowingNewPosting.jar.
BTW what does parameter codebase mean? Is it your application level parameter? I am not sure but make sure that this does not confuse browser with attribute codebase supported by tag applet. This attribute is typically .: <applet codebase="." that means "download jars from current directory". This is the same as to say java -cp . when running java from command line.
BTW, do you know that applets were almost obsolete about 10 years ago? Moreover as far as I can see you included MySql JDBC driver into your class path. You should understand that this will not work in most cases because typically there is a firewall that does not allow JDBC protocol between clients and server.
Related
This question is related to my question
Jetty 11.0.11 - 404 on html file in \src\main\webapp\static - maven embedded fat jar
What --EXACTLY-- does "jar:file" mean as a Java resource reference, vs. just "file:"?
And how is that influenced by the operating system ran under?
E. g. using this resource reference in Jetty webserver, in Windows with Oracle JDK 17, files are found as resources and parsed by Jetty webserver:
file:///D:/Projects/verdi_2/target/classes/static/,AVAILABLE}{file:/D:/Projects/verdi_2/target/classes/static}
Using this resource reference in Jetty webserver, in Ubuntu Linux 20.04 LTS with Oracle JDK 17, NO files are found and nothing can be parsed by Jetty webserver:
jar:file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar!/static
Is there a difference in how a Linux version of JDK interprets "jar:file" vs. how a Windows version of the JDK interprets "jar:file"?
EDIT: The related issue is the Jetty webserver apparently can no longer serve resources directly out of a JAR file it is itself embedded in. This is now a GitHub bug ticket at https://github.com/eclipse/jetty.project/issues/8549
file: is the beginning of a general file url. jar:file: is that for a jar file particularly, with a view to referring (usually) to a particular entry in a jar. Here's an example you can run (obviously with your own jar url) where you can save an entry as a file (given by the parameter to the app)
import java.nio.file.Paths;
import java.nio.file.Files;
import java.net.URL;
public class JarUrl {
public static void main(String[] args) {
try {
URL url = new URL("jar:file:root.jar!/root/a/b.txt");
Files.copy(url.openStream(), Paths.get(args[0]));
}
catch(Throwable t) {
t.printStackTrace();
}
}
}
What --EXACTLY-- does "jar:file" mean as a Java resource reference, vs. just "file:"?
You're mischaracterising the URL a little bit. The string until the first : decides the 'scheme' of a URL, so, the pertinent question is: How does jar: work. The file: part is a smaller aspect of a sub-part of the jar bit.
How does jar: work
The format is jar:(URL-of-jar)!(path-inside-jar)
Where URL-of-jar is itself a valid URL (and file: is just one way to do that. So is http, for that matter), and path-inside-jar is not a URL but a path.
The meaning is: First, resolve the 'URL-of-jar' URL. This gets you a jar file. Then, open the jar file, and retrieve the resource at the stated path.
So, to pull this one apart:
jar:file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar!/static
The jar is located at URL file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar and the resource it is referring to is the /static resource inside the jar found at the given URL.
How does file: work
That's not java-specific; file: is a generally available URL scheme. You can even type it in a web browser. The more general URL formatting scheme is scheme://server/resource, but with file:, server doesn't apply (it is by definition local to the system you are on), so usually its put as file:///foo, i.e. - an empty 'server' part. Because 3 slashes is a drag to type, I guess, file:/resource is allowed by some 'URL parsers', including java's in this regard, so, file:/usr/... simply maps straight to a local folder: /usr/src/verdi/verdi-12-JDK-etc, as in, if you type ls /usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar on the command line on your system, it would show a result (and if it does not, this URL would fail to find anything).
And how is that influenced by the operating system ran under?
It isn't. file URLs are a general concept that work on any platform. Of course, /usr/src/verdi/etc is never going to work correctly on a windows platform. Or on anybody else's machine. The problem isn't "Oh no! This won't run on another OS!". The problem with file URLs, especially absolute ones, is "Oh no! This will not run on any machine other than this one!".
file:///D:/Projects
I've explained the triple slashes earlier. This is the standard windows 'scheme' for how to stick paths in file URLs: Always forward slashes (even though windows normally uses backslashes), and treat the disk letter as if it is a 'drive' in the 'root': /D:/Project is URL-ese for:
D:
cd \Project
There is no difference in OS at all - file: URLs are handled by 'interpret this file URL the way any file URL would be interpreted on this machine'.
The answer to the related question
Jetty 11.0.11 - 404 on html file in \src\main\webapp\static - maven embedded fat jar
which prompted this post is in the long series of posts beneath this GitHub issue for jetty:
https://github.com/eclipse/jetty.project/issues/8549
In essence, eventually I had to first clean up my Maven pom.xml (see this thread for the discussion and for links to a pom.xml example that is compliant with Maven Shade plugin and Jetty 11.0.11 requirements and standards) then at the end of the day hardcode a link to the JAR file to find the HTML, JS, etc. resources Jetty was to serve out as a webpage. Also put in a conditional where, on compiling, I need to specify if the code will run "in-IDE" (in my case, Netbeans 14) or "in-JAR" - e. g. in a detached JRE elsewhere than the Netbeans 14 IDE.
Also dropped using the Jetty WebAppContext class and started rendering web content out of a normal ServletContextHandler.
Hopefully this may help someone upgrading Jetty from Jetty 9.xxx to 11 and finding that it all falls apart.
For details as to why they changed so much, see the GitHub link (the last few entries are apropos.)
The github discussion also contains full working source code (startJettyc method) that solved the issue of getting a 404 in a detached, non-IDE modality where the JAR was being run in an JRE separate from an IDE.
Stefan
So I'm running into a problem here getting an applet to run. The .class file is in another directory and I've learned that you can use the codebase attribute to point to where the file is. Here is my calling code.
<applet codebase="/Cartographer/bin" code="CartographerApplet.class" width="300" height="150"></applet>
Now the .class file i'm looking for is in a package I've deemed Cartographer.
My question is, is there something I'm missing? Or is my code completely wrong? I have a hunch that I'm not doing the codebase part correctly because I don't really know how to provide a shortened path without giving the whole C:\ect\ect\ect path.
Edit: The root directory has the folder Cartographer in it which houses the java project for creating the app. So the path I have is what points to the .class file I need. I've tried using the code attribute with and without the Cartographer package attached to the beginning and I keep getting a class not found exception.
I am getting an exception:
Cannot find symbol: FileUploadException;
I have a piece of code which uses
FileUploadException
The library that needs importing is:
org.apache.commons.fileupload.FileUploadException
The path to my project is :
D:\Projects\website
In the project folder I have each in its folder:
Tomcat, Derby, Website
I have copied:
commons-fileupload.jar and commons-io.jar
into both:
Tomcat/lib and Website/Web-INF/lib
---------------I tried this--------------
just importing the library on its own
import org.apache.commons.fileupload.FileUploadException;
adding the jars to the class path upon build:
javac -cp .;D:Projects\website\Tomcat\lib\commons-fileupload.jar;D:\Projects\website\Tomcat\lib\commons-io.jar com/otrocol/app/*.java
adding them to the Environment variables CLASSPATH
D:Projects\website\Tomcat\lib\commons-fileupload.jar;D:\Projects\website\Tomcat\lib\commons-io.jar
I also tried adding the jars where my .java files are as #Scot Ship suggested
----mentions---
I am not using any IDE
The code contains more unrecognized symbols, but I'm trying to solve one at a time
First time using apache, tomcat, jsp.. please be gentle
Vlad, the web container will automatically look for JARs inside
/WEB-INF/lib
even without any developer intervention. Take note that it's all caps WEB-INF. As long as your JAR is there, it will be in your web application's classpath.
Try to display this in one of your servlets or JSP:
System.getProperty("java.class.path")
and you'll get a better view of what classes and JARs were actually loaded.
Update: After reviewing your question, it appears you're facing issues in compiling the files to begin with and you're doing it outside an IDE.
Take note that when you use -cp in javac like this:
javac -cp .;D:Projects\website\Tomcat\lib\commons-fileupload.jar;D:\Projects\website\Tomcat\lib\commons-io.jar com/otrocol/app/*.java
Whatever value you have set in the CLASSPATH environment variable becomes ignored.
Be absolutely sure that the class FileUploadException is indeed inside one of the JARs you're trying to import: you can view the JAR directly using an unarchiving tool.
Also, change the com/otrocol/app/*.java to com\otrocol\app*.java - you should be using your system delimiter (not that this may affect your problem).
Create a simple HelloWorld in the same location as the file you're compiling, add the SystemOut mentioned above, and compile it the same way you're doing for the concerned file.
Read this http://commons.apache.org/proper/commons-fileupload/faq.html#class-not-found. Probably you have the fileupload jar but you also need commons-io.jar in your classpath as well.
I would like to create and work a signed applet from an applet that I wrote. The applet itself uses a library (owlapi) that has to have the correct write rights in order to save the changes made to the owl repository.
In order to do this I should use a .policy file or signed applets. To make signed applets I followed this manual. I follow that manual on the letter, and yet it doesn't work. I get to the point where I have a signed applet and include it in the html like this:
<applet code="owlapi.LoadOntology.class" archive="owlapi/SignedLoadOntology.jar" height=100 width=1000 MAYSCRIPT>
<param NAME="archive" VALUE='owlapi/Signedowlapi-src.jar, owlapi/Signedowlapi-bin.jar'>
</applet>
When I am testing that applet with the appletviewer (which is recommended in that manual), I get the error
I thought I could solve that by manually compile the code with that library and then create a jar with all those .class files, but that didn't help:
javac -cp owlapi-src.jar:owlapic-bin.jar LoadOntology.java
jar cvf LoadOntology *.class
Does anybody know how to create such a signed applet that uses a some other jar-files?
*update: * after reading this thread, I found out that the owlapi-src and owlapi-bin jars had to be included to the applet in the html an should be signed too. I changed the code to my current testing code, but that still didn't work, since I now have again the
java.lang.SecurityException: Unable to create temporary file
which means that the code from the used owlapi library isn't found.
You probably need not include the -src jar, as I'd expect it to contain the java sources.
I do think you need to provide both your own signed jar and the signed library jar in one and the same applet parameter, as follows:
<applet code="owlapi.LoadOntology.class" height=100 width=1000 MAYSCRIPT>
<param NAME="archive"
VALUE='owlapi/SignedLoadOntology.jar, owlapi/Signedowlapi-bin.jar'>
</applet>
I am using one third party jar in my code. In the jar file , in one of the classes, when I opened the class using de-compiler, the code below is written:
java.net.URL fileURL = ClassLoader.getSystemResource("SOAPConfig.xml");
Now I am using this in my webapplication, where should I place this SOAPConfig.xml so that it will find the fileURL.
Note: I have tried putting this XML in WEB-INF/classes folder. But it is not working. Your help will be appreciated.
In Addition: In the explaination you have given, It is telling me not to use this code snippet inside the third party jar in this way...What is the exact usage of this statement
ClassLoader.getSystemResource will load the resource from the system classloader, which uses the classpath of the application as started from the command line. Any classloaders created by the application at runtime (i.e. the one that looks in WEB-INF/classes) are not on the system classpath.
You need to
Look through the script that starts your server, find out which directories are on the classpath there, and put your SOAPConfig.xml in one of those. If necessary, change the classpath in the script to look in a separate directory that's just used for your config file.
Track down the person who used ClassLoader.getSystemResource in the library, kick them squarely in the nuts, and tell them never to do that again.