Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Applets and Codebase

 
Chris Barrett
Bartender
Posts: 317
24
Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

    webapp
    |
    |----classes
    | |
    | |---applet.jar
    |
    |----WEB-INF
    | |
    | |---applet.jsp
    |
    |----index.jsp

    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.
    I've tried:
    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:

    Cheers!
    Chris
     
    Bear Bibeault
    Author and ninkuma
    Marshal
    Pie
    Posts: 65335
    97
    IntelliJ IDE Java jQuery Mac Mac OS X
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I don't know Applets from a hole in the head, but I'd assume that, like any other resource, the URL should start with the context path.
     
    Bear Bibeault
    Author and ninkuma
    Marshal
    Pie
    Posts: 65335
    97
    IntelliJ IDE Java jQuery Mac Mac OS X
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    P.S. classes might not be the best name for a folder -- too easy to confuse with WEB-INF/classes.
     
    Ulf Dittmer
    Rancher
    Posts: 42969
    73
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    For an applet app, I'd probably keep the JSPs outside of WEB-INF to keep things simple.
     
    Chris Barrett
    Bartender
    Posts: 317
    24
    Eclipse IDE Firefox Browser
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Ulf Dittmer
    Rancher
    Posts: 42969
    73
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I see. Then you should probably use a server-relative path: http://www.coderanch.com/how-to/java/TypesOfPaths which starts withe context path inserted dynamically, like Bear suggested.
     
    Chris Barrett
    Bartender
    Posts: 317
    24
    Eclipse IDE Firefox Browser
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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:

    The Java Tutorial on Applets with JSP never clarifies the correct values for codebase and archive in <jsp:plugin> tags, but the Java Tutorial on using the <applet> tag with HTML does:
    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.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic