I've been tasked with a school project that requires me to use the Java equivalent of ebola. Applets. May this be the one and only time I must work with them...
The instructions are explicit:
When user provides their name in the input FORM they are forwarded to a second JSP that displays an Applet
The second JSP must be deployed under WEB-INF
As such, I have my layout as:
index.jsp forwards to applet.jsp with no problem:
If I move the applet.jsp to the same folder as index.jsp, outside of WEB-INF, the applet works with no problem:
But when I move the applet.jsp back into WEB-INF, I cannot figure out the correct codebase to access the applet.jar one folder farther up the URL path.
codebase="classes/" codebase="/classes/" codebase="../classes/" I cannot use an absolute URL, as the end solution must be deployable by the instructor.
I understand the applet.jar itself cannot go into the WEB-INF, but based on the instructions I'm assuming that a jsp in the WEB-INF that calls an applet outside of the WEB-INF is OK.
What I'm I missing about codebase values? :confused:
Bear Bibeault wrote:P.S. classes might not be the best name for a folder -- too easy to confuse with WEB-INF/classes.
You're right. I'll change the folder to /jars. My bad and thank you for the feedback.
Ulf Dittmer wrote:For an applet app, I'd probably keep the JSPs outside of WEB-INF to keep things simple.
Totally agree. The code works fine if I move the applet.jsp outside WEB-INF. However, the assignment instructions explicitly said that the applet.jsp must be in the WEB-INF as the main JSP page is forwarding to the applet.jsp and the applet.jsp is not supposed to be publicly accessible. The idea is to simulate multiple access points from different JSPs that could all forward to applet.jsp and the user would be none-the-wiser, however all the instructions said was The second JSP must be deployed under WEB-INF.
Honestly, the instructor already said he didn't care if the applet worked since applets are dead. He just wanted to see the page forwarding was done correctly. However, I hate not being able to figure something out that should work based on the assignment instructions. Since it works when applet.jsp is moved outside WEB-INF to the same folder as index.jsp, I know the applet itself is fine. The only thing left I can think of is codebase.
You guys have more important things to do. I was just hoping you might know off the top of your collective super-brains.
If I figure it out, I'll post.
I'm pretty sure no one will ever need this, but since I hate leaving a thread unresolved...
The issue was I should have not been setting the relative path in the codebase attribute. The codebase should have been left at the default of codebase=".". Instead, the relative path needed to be set in the archive attribute preceding the jar filename:
codebase = codebaseURL This optional attribute specifies the base URL of the applet: the directory that contains the applet's code. If this attribute is not specified, then the document's URL is used.
archive = archiveList This optional attribute describes one or more archives containing classes and other resources that will be "preloaded". The classes are loaded using an instance of AppletClassLoader with the given codebase.
The archives in archiveList are separated by commas (,) Note: in JDK 1.1, multiple applet tags with the same codebase share the same instance of a ClassLoader. This is used by some client code to implement inter-applet communication. Future JDKs may provide other mechanisms for inter-applet communication. For security reasons, the applet's class loader can read only from the same codebase from which the applet was started. This means that archives in archiveList must be in the same directory as, or in a subdirectory of, the codebase. Entries in archiveList of the form ../a/b.jar will not work unless explicitly allowed for in the security policy file (except in the case of an HTTP codebase, where archives in archiveList must be from the same host as the codebase, but can have the symbol for parent directory (..) in their paths.)
I take no credit for this solution, as it was the instructor's solution that lead me to understanding the purpose of the archiveList.