Java menu knowledge base: Uploading FAQ

This page covers everything about uploading, from beginner to advanced.

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.
1. ALL the .class files in your delivery package; upload in binary mode
2. if there is a .cab file in your delivery package, upload this in binary mode too
3. if there is a .jar file in your delivery package, upload this in binary mode too
4. the index file(s) (upload in ascii mode)
5. any image resources required (upload in binary mode)
6. the HTML file containing the applet
Software for uploading: we recommend simple FTP transfer applications such as WS_FTP from www.ipswitch.com. These 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 sins.
1. 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?
2. 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.
3. 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 applet files.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. Writing paths into the code tag
  
  <APPLET CODE="http://[mySite]/myApplet.class"> or <APPLET CODE="../../myApplet.class"> will never work, however much you try.
10. 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.
11. 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 file?
12. 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 characters.
13. 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.
14. 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.
15. 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.
16. 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.

© Image Intelligence Software Ltd. 1997-2006
Legal information and privacy policy