
	Corporate Info \| News \| Solutions \| Products \| Partners \| Services \| Events \| Download \| How To Buy
	e-docs \| Site Map \| Search \| Contact \| Glossary \| WebLogic Server Documentation

Technical FAQ: Questions about WebLogic JDBC and applets

FAQ Index

Errors running t3dbping
What's the difference between a Java and a "Java-only" JDBC driver?
Can I use a two-tier driver for a browser applet?
Incompatibilities between Java VMs and the JDBC spec for driver registration
Why do I get a "No suitable driver" message using IE3.01?
Just can't get my browser applet to work!
Why will not my browser applet connect to the database?
My applet works with Appletviewer, but not with a browser . . . ?
Why do I get a Netscape security violation when running an example applet?
What's causing ClassFormatErrors with my applet?

Errors running t3dbping

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.

In the C-shell issue the following command:

  $ setenv ORACLE_HOME path

where path is the path to your Oracle installation.

In the Bourne shell, issue the following commands:

  $ ORACLE_HOME=path
  $ export ORACLE_HOME

where path is the path to your Oracle installation.

When you ping your database using the two-tier utils.dbping utility, the JDBC

driver loads the database client library

and establishes the connection to the database. When you use the multitier utils.t3dbping utility, the WebLogic Server loads a two-tier driver and uses it to establish a database connection. In both cases, the same method is used to connect to the database. SQL*PLUS works because it doesn't require ORACLE_HOME to find the client libraries.

If you are still experiencing problems, try this:

Open a command shell.
Run the two-tier version of utils.dbping in this shell.
Start WebLogic Server in this shell from the command line:
```
$ java -ms32m -mx32m weblogic.server
```
Open a second command shell.
Run utils.t3dbping in the second shell against the server running in the first command shell.

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 or Sybase's DB-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.

WebLogic offers Type 2 "native" JDBC drivers that work only with specific, individual client libraries, for Oracle, Sybase, and Microsoft SQL Server. 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.

Can I use a "native" two-tier driver for a browser applet?

I'm trying to use jdbcKona/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 jdbcKona/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 jdbcKona/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 jdbcKona/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.

Incompatibilities between Java VMs and the JDBC spec for driver registration

There is a discrepancy in the JDBC JDBC

specification. The specification contradicts the Java language and VM

specifications that determine how JDBC drivers are loaded and registered. It appears that the JDBC specification recommends an idiom for loading a JDBC driver that will not work in a strictly implemented VM.

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:

T is a class and a method actually declared in T (rather than inherited from a superclass) is invoked.
T is a class and a constructor for class T is invoked.
A nonconstant field declared in T (rather than inherited from a superclass or superinterface) is used or assigned.

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 jdbcKona/Oracle Driver, you can use:

Class.forName("weblogic.jdbc.oci.Driver").newInstance();

To load the jdbcKona/Sybase or jdbcKona/MSSQLServer driver, you can use:

Class.forName("weblogic.jdbc.dblib.Driver").newInstance();

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.

Why do I get a "No suitable driver" message using IE3.01?

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.

Just can't get my browser applet to work!

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:

Try running your applet in Appletviewer before you move on to testing in a browser. If it doesn't work in Appletviewer, then answer these questions:
1. Did you install the WebLogic classes correctly on your HTTP server? (more information) Don't confuse the absolute path of the WebLogic classes on your HTTP server with CODEBASE. CODEBASE is a configured path that originates from the HTTP Document Root.
2. Is your applet CODEBASE tag in the applet HTML file set correctly? You can test it by copying the contents into the Open or Go To space of a browser window and opening the URL. If your CODEBASE is correct, you should be placed in the classes directory on your website. (more information)
3. If you are using WebLogic JDBC, are you running the WebLogic Server on the same host as your HTTP server?
If you can run your applet in Appletviewer successfully, it still doesn't mean that everything's perfect. You probably have the WebLogic classes installed on the machine you are using to run the applet, and this means that you might not have installed the classes correctly on your HTTP server, but the applet is finding the necessary WebLogic classes anyway, by looking in your local CLASSPATH.
To test your applet in the absence of any local WebLogic classes, temporarily rename the WebLogic directory or try your applet (in Appletviewer) from another machine. Another tip: You can check the HTTP server log to determine which classes are being requested.
Once you have passed these tests, try running your applet in a browser, like Netscape Navigator. If you get a security exception with WebLogic JDBC, it is probably because you are trying to serve your applet from a host that's different from the DBMS host. For more details on this problem, check the next question.

Why will not my browser applet connect to the database?

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.

Another tip: The IP naming format you use in the applet CODEBASE and the constructor for the T3Client must match. That is, you can't use dot-notation in one place and a domain name in the other.

My applet works with Appletviewer, but not with a browser . . .?

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.

There are two possible problems: Either your CODEBASE tag is not set properly in the applet HTML file, or you have not loaded the class files properly on your HTTP server.

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.

For more information about installing the WebLogic classes on an HTTP server, check Using WebLogic for applet programming and Setting up the WebLogic code examples.

Why do I get a Netscape security violation when running an example applet?

I notice when I run a WebLogic example applet, I get a Netscape security violation, although the applet seems to work okay otherwise. Why is this?

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.

What's causing ClassFormatErrors with my 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:

The CODEBASE tag in your applet should point to your HTTP server, not to the WebLogic Server.
The directory path referenced in your CODEBASE tag is not an absolute directory path on the HTTP server; it is a configured path that originates from the HTTP Document Root. You are using the absolute path in your CODEBASE tag.

If your class "myapp" is in the "applets" package, then the correct CODEBASE for your setup would be:

  <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.