|Java menu knowledge base|
This page covers everything about uploading, from beginner
- How to upload
You must upload all of these files before the applet will work. We recommend that
you keep all of these files in the same directory on the server.
- ALL the .class files in your delivery package; upload in binary mode
- if there is a .cab file in your delivery package, upload this in binary mode too
- if there is a .jar file in your delivery package, upload this in binary mode too
- the index file(s) (upload in ascii mode)
- any image resources required (upload in binary mode)
- the HTML file containing the applet
Software for uploading: we recommend simple
FTP transfer applications such as WS_FTP from
make it very clear what is going on and are preferable to more
complex and expensive systems.
- How not to upload
An increasing proportion of the problems reported to us are
occurring during upload. "It worked until I uploaded it"
is becoming more frequent, not least because website structures
are becoming more complex. Here is a list of the most frequent
- Not uploading all the files
It sounds too obvious, especially for the professional web developer.
But it is probably the number one sin. Remember to upload ALL
the .class files. Really all of them. If you can't remember how many
there were, look in the delivery ZIP package again (which you carefully
backed up). Then check whether there was a CAB and/or a JAR file too.
And are these the files your HTML points to? And how about those applet
resources such as text files and images?
- Mixing up trial versions and release versions
You carefully deleted all the trial class files from your
development area and replaced them with the release versions,
just as you should. But when uploading, you forgot that the
files on the server were still trials and you didn't replace them.
The results can be inexplicable and confusing.
- Not ending up with the same files on the server
This one really happens too. The files on your server just
aren't the ones you got working locally. Check filenames. Check
versions. And look at all the files involved - HTML as well as
- Using codebases
Codebases are the devil's own temptation to web developers using
applets. File management problems always result, because the
human brain fails to keep track of the new dimension of complexity.
Codebases are usually unnecessary. Keep your applets and the HTML
files they are embedded in in the same directory and you will be
much happier in the long run.
- Uploading to the wrong directory
As servers and server-side programming becomes more complex,
developers are increasingly tempted to think they have to upload
applets to special directories to get them to work. However applets run
client-side, which means that to the server they are just a heap of
dead binary. The proper place for an applet is alongside normal
HTML files. In fact, putting an applet in CGI-bins and other exotic
locations can even stop them working.
- Uploading in the wrong mode
This used to be a favourite mistake, but may be disappearing
because we have been warning about it for so many years.
CLASS, CAB and JAR files must be uploaded in BINARY mode
(like images). HTML, text and other ascii files (such as
perl, js and other scripting resources) are uploaded in ASCII
mode. Use the wrong mode and your applet won't work.
- Uploading with over-complex software
If you are running version 20 of your $5000 thought-to-code web design
environment, don't necessarily expect it to upload properly. The more
complex the programme, the more that can go wrong and the less likely
you are to see what went wrong. Upload files with the simplest, cheapest software
available. Try Cute FTP or WS FTP.
- Not observing resource relationships
If the applet reads in a resource it requires to run (such as an
icon image or an index file), this resource must either be in the
same directory as the applet, or a sub-directory of the applet's
directory. This does not apply to hyperlinks triggered by the applet,
only to resources used within the applet.
- Writing paths into the code tag
<APPLET CODE="http://[mySite]/myApplet.class"> or
will never work, however much you try.
- Getting confused by browser cache
You uploaded OK, but you can't see the new results. Keep the
SHIFT and CTRL keys pressed with your free hand while you
click on the browser "refresh" button with the mouse. This
will clear cache and display the most recent results.
- Getting confused by development studio cache
You can see the changes in your $5000 thought-to-code web design
environment, but when you click the magic "publish" button, the
changes aren't on your server - and perhaps even the applet isn't
there. Well, does the $5000 thought-to-code web design
environment publish (upload) what it displays, or what you have
clicked five further buttons to save and reserve for publication?
And has it realised that it should upload more than just the HTML
- Getting uppercase names confused
Your server may be case-sensitive. Try to keep everything
lowercase - this is the most reliable strategy. And watch
out for other characters in filenames and directory names which
your server may not agree with. Try to stick just with lowercase
letters and numbers, avoiding spaces, punctuation marks and special
- Failing to use the escapepage feature
If you deactivate the escapepage parameter, our applets produce
error codes which you can look up in this support area. This can
save a lot of time.
- Uploading to unlicenced locations
This happens increasingly on large projects where the
liaison between purchase authorisation and sub-project
implementation is not close. Release applets are licenced
and locked to specific network locations. They are designed
not to work unless they are placed at a licenced location.
Read the licencing FAQ in this support area and read the
original delivery email which came with your software.
- Forgetting to add your keys
Keys are required to unlock the software for the networked
locations it is licenced for. If the software works before
uploading but not afterwards, it may also be because you skipped
reading the delivery email and didn't add the keys (or didn't
add them to the online version of the HTML file). Remember that
there is an error code which signals this problem.
- Incorrect permissions on a UNIX server
By default the permissions should be set correctly. However
if you have played with your server defaults, you may have
problems. The "other-read" permission must be available. For
example, CHMOD 644 is good. And remember that as the applet
runs client-side, not on the server, permissions must be
set correspondingly on any resources the applet tries to access.