I have a very simple java applet, that Im using source code from the docs.oracle(http://docs.oracle.com/javase/tutorial/deployment/applet/getStarted.html) site that should work, and it works in eclipse just fine, it's getting it onto the page that's the problem. The file is on a localhost server at localhost/applet/applet.html and I have the file JavaQuiz.jar in the same directory. My html file is as follows.
<hmtl>
<applet codebase="localhost/applet/"
code = 'JavaQuiz.jar'
archive = 'JavaQuiz.jar'
width = 300
height = 300 />
</html>
Is there something Im missing? Or need to change? I look forward to any help that could be given, and please try to explain it more than telling me the answer so I can learn. :D
This is what is in the java colsole
Java Plug-in 10.5.1.255
Using JRE version 1.7.0_05-b05 Java HotSpot(TM) Client VM
User home directory = C:\Users\Jihoon
c: clear console window
f: finalize objects on finalization queue
g: garbage collect
h: display this help message
l: dump classloader list
m: print memory usage
o: trigger logging
q: hide console
r: reload policy configuration
s: dump system and deployment properties
t: dump thread list
v: dump thread stack
x: clear classloader cache
0-5: set trace level to
plugin2manager.parentwindowDispose
The Chrome developer help thing doesn't show any problems. And when I click details on the applet it just says classnotfounfexception: JavaQuiz
<html>
<applet
archive="http://localhost/applet/JavaQuiz.jar"
code="JavaQuiz.class"
width = 300
height = 300 />
</html>
I think the biggest problem is not having the http:// I'm not entirely sure about the other parameters. Play around with that.
So in your case change codebase="localhost/applet/" to codebase="http://localhost/applet/"
The code attribute should point to a fully qualified class name, not to a jar.
Also you should have an eye on localhost... this means that the j.jar is located in a folder called localhost in the same directory that the html is in. Is that true? Or do you mean http://localhost:80/applet/ or /applet/
<hmtl> should be <html>
The mandatory "code" attribute (which is missing in your example) should point to the class which you intend to run (the one extending JApplet). Something like:
<html>
<applet codebase="localhost/applet/" code="yourpackage.YourApplet.class"
code = 'JavaQuiz.jar'
archive = 'JavaQuiz.jar'
width = 300
height = 300 />
</html>
http://localhost/applet/JavaQuiz.jar will not work at time of deployment.
<html>
<applet
codebase="."
archive="JavaQuiz.jar"
code="JavaQuiz"
width = 300
height = 300 >
</applet>
</html>
Since the code base points to the 'current directory' this will work for the applet while on localhost as well as deployed live.
Points, some of which have already been mentioned:
The code attribute should be the fully qualified class name of the applet class, without .class on the end.
The applet element cannot be 'self closed' - always use </applet> to close the element.
If omitted the code base defaults to the directory the HTML is in, so putting codebase="." is redundant. It should also work without it.
Related
I am facing a strange problem in apache tomcat.Suppose when I load a class in jsp file it gives me output but when i change the java file recompile changing class file the changes are not shown by apache tomcat,it shows result of previous class...for eg:
<html>
<head><title>Hello World</title></head>
<body>
Hello World!<br/>
<%# page import="neww.Simpl" %>
<% Simpl demo = new Simpl();
out.println("Current date : " + demo.retur());%>
<%
out.println("Your IP addresssavxcd is " + request.getRemoteAddr());
%>
</body>
</html>
for the first time it shows correct result now if I change the Simpl.java and recompile it and run this jsp file again tomcat gives me previous result.
P.S. I am sure that the class file is modified.
I think that there is something wrong with what you are doing. In particular:
stop tomcat, delete /temp and /work subdirectories' contents, and start it up again.
I tried that already but no help!! I even tried deleting the class file but then to it gives same output.....
If you deleted the old compiled JSP class file, the work and temp directories and restarted the server .... and still saw the old behaviour, then something must be replacing the new version of the JSP source code with the old version. The only plausible explanation for that is that you are modifying the JSP in-place, and a redeploy (from the WAR?) is clobbering your tweaks. But a redeploy shouldn't happen spontaneously. You must be doing something to cause it.
The only other explanation I can think of is that you are deleting the wrong JSP class files, and it is hard to envisage how that might be happening.
i have a struts2 action which has a variable for an image which i want to display in a jsp page. when i display the value of the variable using the following:
<s:property value="variableName" />
i get the absolute path of the image file.
but when i try the following:
<img src='<s:property value="variableName" />' />
i get a blank there. i have even tried the following:
<img src="${variableName}" />
EDIT: i have done some thinking. the path of the image which is set is in temp folder of tomcat. is it because of that that i am unable to access it?
to no effect. what may be the issue in this?
Always keep in mind when doing web development what you have in server context and what travels to the client browser. If you do what you are suggesting, you will render and send to the client something like this:
<img src="c:\my_local_directory\some_image.jpg"></img>
Which means nothing to the client browser, which is surely executing in some other machine.
You should store your images somewhere where your application server can show them, and give always paths that are relative to your web application. For example, if you have stored some_image.jpg straight in your my-app.war file, something like:
<img src="/my-app/some_image.jpg"></img>
will always work. If you need to refine that image (imagine you need to put a watermark on it before) or need to recover its contents from somewhere (a BLOB in a database or something like that), you will need an entire new action in order to do it, for example:
<img src="/my-app/ImageAction.action?image=some_image"></img>
The src of the img tag must contain an absolute path, then only it can point to the image file from the client machine.
If the variableName contains an absolute path like this
http://localhost/images/pics/icon.gif
The img will finds the image from the server. Thus available always an hence you can use this.
<img src="${variableName}"/>
If the variableName is a relative path ie; something that's recognisable for the server.
/images/pics/icon.gif
The above path will be identified by the server but it wont be identified from the remote machine. In that case you need to have this
<img src="<c:url value=variableName/>" />
I have a site where I am using Java applets and have included deployJava.js load tag in the head area of the page. However when I see resulting HTML in Chrome debugger this script breaks my head content starting body immediately, so other head content appears in body tag!
You can see it live on my site http://viva-games.ru/
Also deployJava inserts an embed tag (right after body opens) so you can see an empty line in the top of page.
What I am doing wrong?
deployJava.js is a pain to integrate since it uses document.write to insert tags in the page before the document is fully loaded. Basically, it doesn't support asynchronous loading.
According to the examples from Oracle, we have to include the file somewhere in the body and call it right after the inclusion. The applet tags will be placed there.
If you want to load it asynchronously using RequireJS for instance or if you want to call it later, after the page is loaded, download the uncompressed version and replace every occurrence of:
document.write(...);
by:
document.getElementsByTagName('body')[0].insertAdjacentHTML('afterbegin', ...);
Then you can call deployJava.runApplet anywhere in your JavaScript. You can even put the applet tags in a div element somewhere in your page. The HTML code:
<body>
...
<div id="appletContainer"></div>
// The include after the div or once the page is loaded
<script type="text/javascript" src="javascript/deployJava.js"></script>
...
</body>
and the file deployJava.js:
document.getElementById('appletContainer').insertAdjacentHTML('afterbegin', ...);
Regarding the empty line, I don't have any explanation but a workaround can be found using CSS. If your applet doesn't show any GUI, you can set the appletContainer's height to 0.
NOTE: Don't hide the appletContainer using display:none, otherwise your applet won't run.
Hey everyone I am making my first applet for java today. I have been using a subdomain at a server and I don't know what to do because I am getting this really weird error.
I have my jar in the server and everything but every time I try to load the Applet this happens.
java.lang.ClassFormatError: Incompatible magic value 218774561 in class file Evolution/EvolutionApplet
Upon research it appears that an incompatible magic value means that something has been corrupted in the .jar
Here is the website http://dementedgames.site88.net/Main.html
the jars name is Evolution if you need the html code it is at the website.
Edit: The applet should be launched from Evolution.EvolutionApplet not Evolution.Evolution
The magic value of a valid Java class is 0xCAFEBABE, which is the hex value of 3405691582. This is represented by the first 4 bytes of the file. But you're getting 218774561 which in turn stands for the ASCII characters CR, LF, < and ! (the CRLF is a newline). To see it yourself, run this piece of code:
int magic = 218774561;
ByteBuffer b = ByteBuffer.allocate(4);
b.putInt(magic);
System.out.println(new String(b.array()));
This in combination with the applet being served by a website suggests that it's the start of a <!DOCTYPE> which in turn suggests that it's a HTML document.
So, the request to Evolution.jar has apparently actually returned a HTML document. You should be able to see it yourself when you change the current request URI in browser address bar to point to applet's URL (e.g. change /page.html in end of URL to /Evolution.jar). Then you'll see what the browser actually retrieved when it tried to download the applet. Perhaps it's a simple HTTP 404 error document.
To fix it, just make sure that the URL in the archive attribute is correct. It's relative to the current request URL as you see in browser address bar.
The original problem seems fixed now. I could download the Jar from http://dementedgames.site88.net/Evolution.jar
Update
It seems the Evolution.Evolution class is not an applet! Running it from the command line using:
java -jar Evolution.jar
Produces a frame (with a very 'retro' look)! As such, forget this applet nonsense, and launch the frame from a link using Java Web Start.
Old Answer
OTOH it now throws a ClassNotFoundException that (after inspecting the Jar) makes me think it should be:
<html>
<head>
<title>Evolution</title>
</head>
<body bgcolor="#000000" text="#906060">
<center>
<applet code="Evolution.Evolution" archive="Evolution.jar" width="800" height="600">
</applet>
</center>
</body>
</html>
There are two changes to the code attribute worth noting.
The .class extension was removed. A minor matter, adding it is tolerated, but not correct.
The Applet removed from the class name.
BalusC above has explained it really well. In addition to that you can check this link
Thread: Incompatible magic value 218774561 error in applet
It seems that the codebase and/or the code attribute of ur applet tag need to pointed properly.
Is there a way to set the default buffer size for JSPs in Tomcat? I know I can set them on every page, but am hoping there's a global option somewhere.
Short answer: No.
Long answer: Perhaps, with some hacking...
You'd have to build Tomcat yourself after editing this class: Jasper constants
...or you can do a Perl pie, and edit all your JSPs all at once. Back-up first as this edits in-line:
For directives without the buffer set:
/usr/bin/perl -pi -e 's|<%# page|<%# page buffer="new" |g' `find . -type f -name '*.jsp'`
For already-set buffers:
/usr/bin/perl -pi -e 's|buffer="old"|buffer="new"|g' `find . -type f -name '*.jsp'`
(If your directives are inconsistent with the above, e.g. more/less whitespace, please use more regexp magic to make it work)
Your problem elsewhere on the web: http://www.theserverside.com/discussions/thread.tss?thread_id=24768
HTH
EDIT: To lift the comments discussion to this answer - this might be what you're after
When you're stuck with a legacy application even without separation of processing (controller) and view (jsp), you should limit your processing to the very first instructions on a jsp, e.g. right on top. There you're even free to redirect (e.g. send back response code 302), let alone signal errors with the correct error code. That said, you should avoid presenting 500 style errors to your customers anyway. Rather deliver a nice looking html page (200), displaying a helpful error message to the customer. Applications should display their errors on their level, not on a protocol level.
I remember, back in the last century, to have worked on such an application myself. We have experienced some platform differences: One platform didn't buffer even the first byte but immediately sent it back to the customer, rendering our redirection attempts (code 302) useless, as the 200-code header was already on it's way. The only thing that helped was to make sure that not a single byte could have been sent prior to the processing. As we've needed some taglibs, we've had to eliminate the linebreaks between taglib instructions. There's two ways to do this:
Instead of
<%# taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %>
<%# taglib uri="http://java.sun.com/jstl/fmt_rt" prefix="fmt" %>
<% /* your processing instructions here */
response.sendRedirect("somewhere.jsp") %>
write
<%# taglib uri="http://java.sun.com/jstl/core_rt" prefix="c"
%><%# taglib uri="http://java.sun.com/jstl/fmt_rt" prefix="fmt"
%><% /* your processing instructions here */
response.sendRedirect("somewhere.jsp") %>
or use jsp comments to eliminate line breaks:
<%# taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %><%--
--%><%# taglib uri="http://java.sun.com/jstl/fmt_rt" prefix="fmt"%><%--
--%><% /* your processing instructions here */
response.sendRedirect("somewhere.jsp") %>
This might look ugly but greatly reduces the danger of the server flushing the buffer - no matter how big it might be.
Hope this helps.
This is what was answered prior to / during the comments discussion
The Tomcat docs for the http connector have bufferSize, socketBuffer and several more options for the nio installation - some for input- and some for output streams. The AJP connector seems not to be that configurable (you need the ajp connector if you use Apache/mod_jk).
I hope that the buffer you're looking for is among these...
EDIT: (The comment space has been too small, so I chose to add some more information regarding your comment that you use AJP here:)
The wisdom about buffer sizes seems to be implemented (from a brief look at the tomcat 6.0.18 source code) in org.apache.catalina.connector.OutputBuffer and in org.apache.catalina.connector.Response. Of particular interest is this piece of code (from Response):
/**
* Set the Connector through which this Request was received.
*
* #param connector The new connector
*/
public void setConnector(Connector connector) {
this.connector = connector;
if("AJP/1.3".equals(connector.getProtocol())) {
// default size to size of one ajp-packet
outputBuffer = new OutputBuffer(8184);
} else {
outputBuffer = new OutputBuffer();
}
outputStream = new CoyoteOutputStream(outputBuffer);
writer = new CoyoteWriter(outputBuffer);
}
Basing my judgement on this piece of code, it seems that increasing buffer size might not really be helping your issues. Not that I would like to say that it doesn't help... Did you measure actual performance when you increase buffer size from jsps? Does it help to do so?
With the knowledge of this point of contact you might suffice by either patching the tomcat source or by adding a filter to your web application or tomcat container configuration that tweaks the buffer size according to your needs. (I'd prefer the filter over the tomcat patch any time)
Another idea that comes to my mind is: If you use any templating system (like tiles, as you are mentioning jsp, but velocity or others come to mind) you shouldn't have too many points where you'd have to set the buffer size from jsps. In systems I've worked on I probably would guess that around 10 basic layout templates would be affected (independent of project size).
I hope that this addition helps...