|
Quick Lists
|
|
Bug ID:
|
4456393
|
|
Votes
|
20
|
|
Synopsis
|
(api) getDocumentBase and getCodeBase do each other's jobs.
|
|
Category
|
guides:none
|
|
Reported Against
|
1.3
, 1.4
, 1.2.1
, 1.3.1
, 1.4.1
, hopper
, 1.0-b68
, 1.3.1_03
, hopper-beta
, merlin-beta
, merlin-beta2
|
|
Release Fixed
|
1.4.2(mantis-b14)
|
|
State
|
10-Fix Delivered,
bug
|
|
Priority:
|
3-Medium
|
|
Related Bugs
|
4252701
,
4472003
,
4504372
,
4710854
,
4070158
,
4077547
,
4274668
,
4430345
|
|
Submit Date
|
09-MAY-2001
|
|
Description
|
According to the 1.3 API doc, getDocumentBase() is supposed to
return the URL of the directory of the document in which an applet
is embedded. According to the 1.3 API doc, getCodeBase is supposed
to return the URL of the applet itself. The actual behavior is
reversed and has been reversed for a long time.
algol% cat SimpleApplet.java
import java.applet.Applet;
import java.awt.Graphics;
import java.awt.Color;
public class SimpleApplet extends Applet{
public void init() {
setBackground(Color.cyan);
}
public void start() {
System.out.println("starting...");
}
public void stop() {
System.out.println("stopping...");
}
public void destroy() {
System.out.println("preparing to unload...");
}
public void paint(Graphics g){
System.out.println("Paint");
g.setColor(Color.blue);
g.drawRect(0, 0, getSize().width -1, getSize().height -1);
g.setColor(Color.red);
g.drawString("getDocumentBase: "+getDocumentBase(), 15, 25);
g.drawString("getCodeBase: "+getCodeBase(), 15, 35);
}
}
algol% cat SimpleApplet.html
<HTML>
<BODY>
<APPLET CODE=SimpleApplet.class WIDTH=200 HEIGHT=100>
</APPLET>
</BODY>
</HTML>
I tested a large number of JDKs and found that the results have been stable
for a long time (at least on Solaris/sparc):
getDocumentBase file:/home/ajacobs/public_html/BasicJava1/SimpleApplet.html
getCodeBase file:/home/ajacobs/public_html/BasicJava1/
The JDKs checked: 1.1.6, 1.1.7, 1.1.8_13, 1.2 FCS, 1.2.1_004, 1.2.2_008,
1.2.2_08, 1.3.1, and 1.4.
Testing on Merlin (1.4) shows that behavior is consistent on Windows and
customer /Solaris.
According to the JDK 1.3 API documentation, the results should have been
getCodeBase file:/home/ajacobs/public_html/BasicJava1/SimpleApplet.html
getDocumentBase file:/home/ajacobs/public_html/BasicJava1/
xxxxx@xxxxx 2001-05-09
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
In the API, getDocumentBase() is listed as "Return(ing) an absolute URL naming
the directory of the document in which the applet is embedded." However
getDocumentBase(), when a toString() is used prints "the URL of the applet
itself" -- the function listed for getCodeBase(). A Simalar screen print of the
toString() of getCodeBase() displays the base directory of the applet.
Please contact me if I have misinterpreted the API.
I have found this discrepancy on VM's 1.3.1 and 1.3.0.
(Review ID: 134789)
======================================================================
|
|
Work Around
|
Ignore the documentation.
Use getCodeBase to to the work of getDocumentBase.
Use getDocumentBase to do the work of getCodeBase.
xxxxx@xxxxx 2001-05-09
|
|
Evaluation
|
This is not necessarily a documentation problem. It is possibly a problem
with AppletViewer's implementation of the java.applet.AppletStub interface.
Does this same behaviour exist in Plug-In?
xxxxx@xxxxx 2001-05-10
JDK 1.4 plugins are not functional. I failed to get a JDK 1.4 plugin
to work in Netscape 4.75, 4.76, and Netscape 6.01A.
JDK 1.3.1 plugins behave incorrectly. The behavior is different from
that in appletviewer. Maybe there are two bugs. Both getDocumentBase
and getCodeBase return the directory name.
Java2Applet.html is attached. Referencing SimpleApplet.html is run
by the JDK 1.1 JRE bundled with Netscape 4.75.
xxxxx@xxxxx 2001-05-10
Here's another note from xxxxx@xxxxx :
Nice catch. The JDK 1.3.1 plugin returns
http://sqesvr.eng/~ajacobs/BasicJava1/
from getDocumentBase(), and the same
http://sqesvr.eng/~ajacobs/BasicJava1/
from getCodeBase().
JDK 1.3.1 appletviewer (and JDK 1.4 appletviewer) returns
http://sqesvr.eng/~ajacobs/BasicJava1/SimpleApplet.html
from getDocumentBase(), and
http://sqesvr.eng/~ajacobs/BasicJava1/
from getCodeBase().
The documentation says that the correct values should be
http://sqesvr.eng/~ajacobs/BasicJava1/
from getDocumentBase(), and
http://sqesvr.eng/~ajacobs/BasicJava1/SimpleApplet.html
from getCodeBase().
My attempt to get a JDK 1.4 plugin to work have so far
failed. Netscape 6 core dumps. Netscape 4.75 refused to
take it.
This is not going to get fixed in 1.3.1. I'll leave it
a Merlin bug and move it back to subcategory=appletviewer.
I will try one more time to get a JDK 1.4 plugin to work
in a browser. If I fail, I will get help from the plugin
testers.
So, it looks like Plug-In and AppletViewer are both having problems with
correctly implementing the spec. Since Plug-In owns the spec, they need to
decide what (if any) modifications need to be made to the API for
getCodeBase() and getDocumentBase() in java.applet.Applet and
java.applet.AppletStub.
I designate this as the "spec" bug. Additional bugs may be necessary to track
work to update AppletViewer and Plug-In to properly implement the spec.
Routing the bug to xxxxx@xxxxx who owns the spec for java.applet.
xxxxx@xxxxx 2001-05-11
Engineering has provided the following text as a fix to this doc problem (no code change):
/**
* Gets the URL of the document in which this applet is embedded.
* For example, suppose an applet is contained
* within the document:
* <blockquote><pre>
* http://java.sun.com/products/jdk/1.2/index.html
* </pre></blockquote>
* The document base is:
* <blockquote><pre>
* http://java.sun.com/products/jdk/1.2/index.html
* </pre></blockquote>
*
* @return the {@link java.net.URL} of the document that contains this
* applet.
* @see java.applet.Applet#getCodeBase()
*/
public URL getDocumentBase() {
return stub.getDocumentBase();
}
/**
* Gets the base URL. This is the URL of the directory
* which contains this applet.
*
* @return the base {@link java.net.URL} of
* the directory which contains this applet.
* @see java.applet.Applet#getDocumentBase()
*/
public URL getCodeBase() {
return stub.getCodeBase();
}
xxxxx@xxxxx 2002-10-23
|
|
Comments
|
Submitted On 15-JUN-2001
hongmeid
I just tested it with the plugin 1.4beta. Now
getDocumentBase() and getCodeBase() both return the URL of
the applet itself. Please get it fixed in the official 1.4
release.
Submitted On 17-SEP-2001
potel
Seems to me this explains bug #4294902, which I logged in Nov 99 but was closed as "not a bug". If you
open an HTML document with JTextPane, it should search for images in the document folder, and indeed it
did so in JDK 1.2. But ever since 1.3 beta it searches in the code folder, apparently because
getDocumentBase() behaves like getCodeBase() as reported here. Also, looks like 4252701 and 4472003 are
the same bug.
Submitted On 02-NOV-2001
herteg
The behavior in 1.3.1_01 depends on which browser you're
using. In IE6 and in NS4.78 we seem to get reasonable
results from getDocumentBase(). But in NS6.1 we get the
full URL of the applet's document, not just the directory,
from getDocumentBase(). All of this is on Windows NT 4.0.
Submitted On 04-OCT-2002
petewilliams
The author of the description above has misunderstood the
meaning of "codebase". He does not allow for the case where
the APPLET tag has a CODEBASE attribute specified. This will
cause the applet code to be dowloaded from a different
directory from the document itself. To cater for this, you
need to have both getCodeBase() and getDocumentBase(). In
the simple case shown above, they will both return the URL to
the directory where the page and code are. Where the
CODEBASE attribute has been given, you need both API calls
to get the two different URLs: one for where the page was
downloaded from, the other for where the code was
downloaded from. Our applets rely on this!
He is right to say that getDocumentBase() returns the wrong
thing (it should return the directory), but getCodeBase()
should return the same thing in his simple example.
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
|
