Technical FAQ: Questions about WebLogic JDBC and appletsFAQ Index
I am testing my Oracle database connections under UNIX. I am able to run SQL*Plus and can successfully ping the database using utils.dbping. However, when I use the multitierutils.t3dbping utility, I receive an ORA-12154 error message. What's going on?
First, make sure that your ORACLE_HOME environment variable is correctly set to point to your Oracle installation. This variable must be set in the environment where the WebLogic server is running.
If you are still experiencing problems, try this:
If this procedure doesn't work, please send the output from these commands to WebLogic technical support.
What's a "native" JDBC driver? What's the difference between a Java and a "Java-only" JDBC driver?
Why are some JDBC drivers billed as "Java-only?" What's a "native" JDBC driver?
Some JDBC drivers written in Java work by calling database vendors' platform-specific database client libraries, such as Oracle's OCI Library. These libraries are written in C, not Java. A JDBC driver that uses these native libraries uses a Java mechanism called Java Native Interface (JNI) that makes it possible for a Java program to access platform-specific native code. There are some restrictions on how and where native methods can be used. For example, Java JDBC drivers are not appropriate for use in Netscape applets because of restrictions on the use of native methods.
BEA offers a Type 2 "native" JDBC driver that work only with the client libraries for Oracle. Because the vendors' client libraries are not written in Java, the WebLogic native drivers use a very thin C layer to make calls into the client library. This WebLogic native layer is supplied as a .dll for Windows or an .so or .sl for UNIX. When you use a WebLogic native driver, you need the WebLogic Java classes as well as the appropriate native library for the vendor library for your database.
WebLogic also provides a Type 3 pure-Java JDBC driver, WebLogic JDBC. A pure-Java JDBC driver does all of its work exclusively in Java, without any use of native methods, which is how WebLogic JDBC works. WebLogic JDBC can be used within the WebLogic framework without accessing any vendor-specific database libraries.
In addition, WebLogic supplies Type 4 pure-Java two-tier drivers for Informix and Microsoft SQL Server. These can be downloaded separately from the WebLogic website.
I'm trying to use jDriver for Oracle from an applet, but I get errors and my applet doesn't work. I've heard rumors that you can't use two-tier drivers from applets. Why not?
The rumors are correct. Within an unsigned applet, you cannot load native libraries over the wire, access the local file system, or connect to any host except the host from which you loaded the applet. The applet security manager enforces these restrictions on applets as protection against applets being able to do unsavory things to unsuspecting users.
If you are trying to use jDriver for Oracle from an applet, then you are violating the first restriction. Your applet will fail when it attempts to load the native (non-Java layer) library that allows jDriver for Oracle to make calls into the non-Java Oracle client libraries. If you look at the Exception that is generated, you will see that your applet fails in java.lang.System.loadLibrary, because the security manager determined that you were attempting to load a local library and halted the applet.
You can, however, use WebLogic JDBC in applets. WebLogic JDBC is a pure-Java implementation of JDBC that operates within the WebLogic Server. With WebLogic JDBC, you need one copy of jDriver for Oracle (or any other two-tier JDBC driver) for the connection between the WebLogic Server and the DBMS. WebLogic JDBC provides a pure-Java JDBC connection to the WebLogic Server that is appropriate for applet use.
The idiom that the JDBC specification recommends is to load and register a driver by calling Class.forName("name.of.Driver") (according to the javadoc documentation for java.sql.Driver).
This is contradicted in section 8.5 of the java language specification:
Any static initializers declared in a class are executed when the class is initialized and, together with any field initializers (8.3.2) for class variables, may be used to initialize the class variables of the class (12.4).
The VM specification also states that,
Initialization of a class consists of executing its static initializers (2.11) and the initializers for static fields (2.9.2) declared in the class . . . A class or interface type T will be initialized at its first active use, which occurs if:
The result of this contradiction is that in a strictly implemented VM, you cannot guarantee that the Class.forName() call will load and register the Driver unless you call newInstance() on the class. This only works if the Driver class has a public default constructor, which is the case with all of WebLogic's drivers.
For example, to load the jDriver for Oracle Driver, you can use:
And that will guarantee that the driver is properly loaded and registered, and that you can use it, given an appropriate URL. With any driver that does not implement (implicitly or explicitly) a public default constructor, this idiom will fail for that driver.
We expect that JavaSoft will announce a change to the Java Language Specification that will make Class.forName() an active use of a class and cause static initialization blocks to be executed. However, to be safe we recommend using newInstance() for the indefinite future.
I'm using WebLogic JDBC. Code that works in Netscape and the Appletviewer fails in Internet Explorer 3.01 with a "No suitable driver" message. What's the problem?
The problem is that IE3.01 is not invoking a static block in the WebLogic JDBC class weblogic.jdbc.t3client.Driver when you load the WebLogic JDBC driver by calling Class.forName(). It is likely that Microsoft will fix this. You can work around this bug by using a different method to load the driver. Replace these lines of code (where "props" is a java.util.Property object):
Class.forName("weblogic.jdbc.t3client.Driver"); Connection c = DriverManager.getConnection("jdbc:weblogic:t3client", props);with the following:
Driver d = new weblogic.jdbc.t3client.Driver(); Connection c = d.connect("jdbc:weblogic:t3client", props);This solution works equally well with Netscape and Appletviewer.
I've tried everything, and I just can't seem to get my browser applet to work! Any suggestions?
If you haven't yet read it, check Using WebLogic for applet programming. Here are some other troubleshooting tips for applet debugging:
I'm using WebLogic Express' multitier driver (WebLogic JDBC) in an applet as an interface to 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. What's wrong?
If Appletviewer works and Netscape does not, 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.
I tried two of the applets in the examples directory of the distribution. I installed the WebLogic classes on my local machine (NT server) and on another machine (a Windows 95 client), and I'm not using any browsers, just trying to run the applets with Appletviewer. The applets work fine when I run Appletviewer from the NT server, but do not work at all from the Windows 95 client.
The reason the applet works on your NT server is this: You have installed the WebLogic distribution on your NT server, and even if the applet cannot successfully load the necessary classes from the HTTP server, it does find them in your local CLASSPATH. But when you try to run it from the Windows 95 client, the applet must load the classes over the wire from the HTTP server, and if you haven't installed them correctly, it will fail.
If an applet is using WebLogic JDBC (which the WebLogic example applets use), Netscape will report a security violation caused by the JDBC DriverManager looking for a property. It doesn't affect the applet. You can ignore the security violation.
I installed the WebLogic example applets, and they work fine with a Netscape browser on my machine. But when I try to view the applet from another machine on the network, I get a security violation. By the way, the applets and the HTML files in the examples are not on my machine. Here is the stack trace:
Applet exception: class examples/applets/PhoneBook2 got a security violation: method verification error java.lang.VerifyError: examples/applets/PhoneBook2 at java.lang.ClassLoader.resolveClass(ClassLoader.java.143) at netscape.applet.AppletClassLoader.loadClass (AppletClassLoader.java:127)etc. Any clues?
Yes. Netscape requires that the WebLogic Server run on the same machine as the HTTP server from which you served the applet.
I downloaded your distribution and copied the classes to my HTTP server DocumentRoot. I created an applet that I was able to run successfully from my Netscape server. I placed it in the server directory /webz/ns-home/classes/applets/myapp.class and calling it with the following:
<APPLET CODEBASE=http://myserver.com/webz/ns-home/classes CODE=applets.myapp.class>Then I set my WebLogic Server properties in the weblogic.properties file to listen on port 7001, and I started the WebLogic Server on the HTTP machine so I could use my applet with WebLogic JDBC, like this:
<APPLET CODEBASE=t3://myserver.com:7001/webz/ns-home/classes CODE=applets.myapp.class>But when I changed the CODEBASE tag to point to the WebLogic Server, I started getting ClassFormatErrors.
There are several problems with your setup. The most obvious have to do with your CODEBASE:
<APPLET CODEBASE=http://myserver.com/classes CODE=applets.myapp.class>More help:
If you are getting a ClassFormatError, it signals a problem with your HTTP server configuration. It could be that you haven't loaded the WebLogic or applet classes in the correct directory on the HTTP server, or you are specifying the CODEBASE or the CODE incorrectly in your APPLET tag. (more information)
Remember, too, that if you installed the WebLogic distribution on the machine from which you are running the applet, your applet will first look for the WebLogic classes in your local CLASSPATH, which may obscure the fact that you haven't properly installed the classes for serving from the HTTP server. 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.
Copyright © 2000 BEA Systems, Inc. All rights reserved.