Using Applets with WebLogic Server
BEA supports the use of applets in limited cases and this document provides other options to help you evaluate your use of applets. For those of you who are working with systems that utilize applets with WebLogic Server outside of our recommended best practices, links are provided to the Sun site for your support.
This section provides a brief overview of applet functionality. For more information, read about Applets on Sun's Java Web site.
When a Web browser requests the HTML page containing the
<APPLET> tag, it attempts to find the main applet class referenced by the
CODE attribute. The Web browser requests the class from the URL specified by the
CODEBASE attribute. Any other classes that the applet uses are requested from the URL specified by
You should be careful when testing your applet, that the Web browser classpath does not contain any of your applet classes. If the browser cannot retrieve the requested class from the HTTP server, it looks in its local classpath. This may fool you into thinking that you have configured you applet deployment correctly since it works on your local host machine. Yet, when someone attempts to use the applet from a remote client it will fail if you have not deployed all of the required applet classes on your Web server.
BEA supports the use of server-side applications with HTTP servlets and Java Server Pages (JSPs) as part of the J2EE platform. We recommend that before you develop new applications, consider using either servlets or JSPs. A well-designed series of interactive web pages using servlets and Java Server Pages (JSPs) generally yield a faster and more reliable website. If you are currently using applets, you may find that most can be converted to Java applications using Java Web Start and you can continue using WebLogic Server. For information, go to Sun's Java Web Start site.
You may use applets as part of your distributed application running on WebLogic to provide a more interactive client-side interface in a web browser. In the case of graphics that require that information to be updated over time, applets are a best practice. Applets provide the advantage of running safe client-side code without the need to distribute software.
Applets may be used to extend the functionality of a page, such as in a stateless, click/respond type of application (i.e., a navigation bar or console), or in a polling application (i.e., a stock ticker).
For information on which browsers and plug-ins have been tested with applets and WebLogic Server, see Browser Support for Applets on the Platform Support page.
If you use an applet in a Web Application and the applet accesses an EJB deployed with another application, you must include the EJB stubs as part of the Web application. To do this, generate stubs using the
-disableHotCodeGen option to
ejbc, and package the stubs as part of the Web Application.
The ContextClassloaders for the event handling threads are different from the ContextClassloader of the the thread that runs the lifecycle methods. Only the ContextClassloader that runs the lifecycle methods has information about the classes that it loaded from the codebase.
If you try to get the
initialContext in any thread other than the thread that runs applet lifecycle methods (
ClassNotFoundException may be thrown under the following circumstances:
actionPerformed()method of your applet (which implements ActionListener)
getInitialContextmethod in an applet and this method is called from the JSP, i.e.
When the Weblogic Server client in the applet tries to get some resouce information from the classloader and the cache tags and
codebase=/bea_wls_internal/classes tag are used together, a
ClassCastException may be thrown.
cache_archivewhile using the classpath servlet as codebase.
ClasspathServlet) as codebase, while using the cache options. To do this, initially package the client side JAR file using the archiver utility.
For more information about this limitation, see http://developer.java.sun.com/developer/bugParade/bugs/4648591.html.
Sun provides a browser plug-in that allows applets to run within the standard Java Runtime Environment, instead of the browser's default virtual machine. This ensures consistency in any browser that supports the plug-in, which means compatibility and reliability for your applets. The plug-in also allows you to conveniently determine which JRE is used on the client machine.
The Java Plug-in provides essential compatibility for your applets if they need to communicate with the WebLogic Server. In most cases, the version of the Java virtual machine (JVM) on the client must match the version of the JVM on the server. That is, if the server is running under Java 1.3, then you must use the Java 1.3 Plug-in.
You can find more details at Sun's Java plug-in homepage. The Java Plug-in is a native plug-in for the Internet Explorer or Netscape browsers. When a user first hits a page that requires the plug-in, a message directs them to Sun's Web site to download it. The plug-in need only be downloaded once. The plug-in runs the applet on a stable release of a specific JRE from Sun, yet can run inside the browser like a regular applet.
The plug-in can be tricky to embed into your HTML pages since Internet Explorer and Netscape each use a different syntax. At Sun's Web site are instructions on how to hack both syntax formats into the same HTML file, or you can download the HTML-converter, which will automatically convert your existing
<APPLET> tags. As you will see, the workaround is quite ingenious, but contrived and difficult to maintain. BEA recommends you evaluate JavaServer pages as a better solution.
In JSP, you use the
<jsp:plugin> tag to include an applet into a JSP generated web page. The generated servlet detects the type of client Web browser, and sends the appropriate plug-in tags in the response. For more details see Programming WebLogic JSP.
The applet JVM requirements are the same as the stand-alone client JVM requirements. If the stand-alone client must be run on the 1.3 JVM for WebLogic 6.1 server, the applet client should be run on the 1.3 plug-in.
<HEAD><TITLE>Title of Applet page</TITLE></HEAD>
WIDTH = 600
HEIGHT = 350
<PARAM NAME = CODE VALUE = "Applet1.class">
<PARAM NAME = CODEBASE VALUE = "/bea_wls_internal/classes/DefaultWebApp@DefaultWebApp/">
<PARAM NAME = ARCHIVE VALUE = "weblogic.jar">
<PARAM NAME="type" VALUE="application/x-java-applet;version=1.3">
<PARAM NAME="scriptable" VALUE="false">
CODE = "Applet1.class"
CODEBASE = "/bea_wls_internal/classes/DefaultWebApp@DefaultWebApp/"
ARCHIVE = "weblogic.jar"
WIDTH = 600
HEIGHT = 350
alt="Your browser understands the <APPLET> tag but isn't running the applet, for some reason."
Your browser is completely ignoring the <APPLET> tag!
You use the
CODEBASE attribute in an <
APPLET> tag to specify a URL where the browser should look for the applet's Java class files. Without the
CODEBASE tag, a Web browser will look for the required classes under the same directory as the HTML file containing the
<APPLET> tag. Using
CODEBASE is convenient, since it allows you to organize your class files under a single directory, separate from the HTML content of your site.
Applets written to work with the WebLogic Server often require WebLogic classes, so it is good practice to use the
CODEBASE attribute to allow the browser to load the required classes out of the WebLogic installation. WebLogic automatically provides a special servlet, mapped to /classes, that serves classes from the WebLogic Server's classpath. The servlet is registered by default under the virtual servlet name "classes". When you set
CODEBASE to a URL such as:
For information on Serving Resources from the CLASSPATH with the ClassPath Servlet see Configuring Web Application Components in Assembling and Configuring Web Applications.
CODEBASE=/bea_wls_internal/classes/DefaultWebApp@DefaultWebApp, the classes required by the applet should be in the
applications/DefaultWebApp/WEB-INF/classes directory or in the system classpath.
<APPLET> tag must contain the
CODE attribute, which specifies the full package name of the main applet class file. The extension ".class" at the end of the
CODE is optional. For example, if you are working with the GraphApplet, your
<APPLET> tag looks like this:
For more information on the
<APPLET> tag and
CODEBASE, see JavaSoft's Overview of Applets in the Java Tutorial.
I'm using WebLogic JDBC in an applet to retrieve data from a DBMS. If I run the class using the Sun Appletviewer on my local machine, I have no problems. But when I try to run the applet in a Netscape browser, it will not connect.
If your applet works in Appletviewer but not in a browser, it is an indication that you are violating a Netscape security restriction; in this case, the violation is that an applet cannot open a socket to a machine other than the one from which it loaded the applet. To solve this problem, you will have to serve your applet code from the same machine that hosts the DBMS.
Note: The IP naming format you use in the applet
CODEBASE and the URL you use to make a connection to the WebLogic Server must match exactly. You can't use dot-notation format in one place and domain name format in the other.
If you are getting a
ClassFormatError, it probably indicates that there is a problem with your HTTP server configuration. It could be that you haven't put the WebLogic or applet classes in the correct directory on the HTTP server, or that you are specifying the
CODEBASE or the
CODE incorrectly in your
APPLET tag. Here are two examples:
This will download all the classes and resource files from the MyWar webapp. Keep all the resource files (JPG files , JAR files, etc.) in the
WebApplicationRoot of the specific webapp which, in this case, is the root directory of MyWar.
If you want to test the codebase in the applet having
CODE=com.myapp.MyApplet, you can frame a URL such as
http://server:host/CODEBASEvalue/com/myapp/MyApplet.class and try this from the browser window. You should get a download window for this class. Otherwise you need to fix the configuration with the webapp in the server.
For more information, see Programming WebLogic HTTP Servlets.
If you are running the WebLogic Server and Netscape Communicator 4.x on the same host, you will need to remove the
CLASSPATH from the environment of the shell that is running Communicator. For security reasons, Netscape Communicator will not load classes from your local
CLASSPATH in order to prevent malicious changes to standard classes. Removing the local
CLASSPATH when running the browser causes Netscape to load the classes from the WebLogic Server's
You will still need to set a
CLASSPATH in the shell in which you start WebLogic. WebLogic recommends that you never set
CLASSPATH in your environment, but rather set
CLASSPATH appropriately in the shell from which you run WebLogic.
We recommened testing the prototyped application on an applet before developing the entire application. We recommend testing for problems that cannot be resolved on the WebLogic Server side because they are the result of a dependency on the applet plug-in. This testing is recommened for:
If you are running the applet on the same machine that you installed the WebLogic distribution, this may obscure problems you are having with
CODEBASE. The applet will first look for the WebLogic classes in your local
CLASSPATH. If you haven't properly installed the classes for serving applets from the HTTP server, the applet will default to your local
CLASSPATH and work, obscuring the problem. To test your HTTP configuration properly, you need to temporarily rename the WebLogic classes in your local
CLASSPATH or try your applet from another machine.
WebLogic has utilities that scan an HTML server log and create a zip file of classes for an applet to speed up file downloading. An even faster alternative is to avoid JDBC in the applet when possible, and obtain DBMS data in HTML form from servlets instead. Servlets can run queries for the applet, and/or retrieve data from Workspaces and supply it as HTML. In concert with WebLogic processes which asynchronously maintain this data, the performance of your applications will improve.
If your applet must download many files before it can run, you can speed this up by using the ARCHIVE parameter inside the
APPLET tag on your HTML page. A common problem with multifile applets is that the browser must make a separate HTTP connection for each file used in an applet. Making a connection can take up to several seconds, sometimes longer than downloading the file itself. With the
ARCHIVE parameter you can combine these classes into a .jar file (or .cab file, for Microsoft Internet Explorer), which can then be downloaded in a single HTTP connection. Since JAR files can be compressed (CAB files are always compressed), this will also improve download time.
Note: The procedure when using Appletviewer, Netscape Navigator (3.0 and later only), and the HotJava browser differs from that used for Microsoft Internet Explorer (4.0 and later only). For complete compatibility, both methods may be combined.