1. Developing Standalone Clients for Oracle WebLogic Server
  2. Developing a WebLogic Full Client (Deprecated)

3 Developing a WebLogic Full Client (Deprecated)

Learn how to develop and use WebLogic full clients.

Note:

The WebLogic full client, wlfullclient.jar, is deprecated as of WebLogic Server 12.1.3 and may be removed in a future release. Oracle recommends using the WebLogic Thin T3 client or other appropriate client depending on your environment. For more information on WebLogic client types, see Table 1-1.

This chapter includes the following sections:

Understanding the WebLogic Full Client

For WebLogic Server 10.0 and later releases, client applications need to use the wlfullclient.jar file instead of the weblogic.jar. A WebLogic full client is a Java RMI client that uses Oracle's proprietary T3 protocol to communicate with WebLogic Server, thereby leveraging the Java-to-Java model of distributed computing.

To understand WebLogic T3 communication, see Using WebLogic RMI with T3 Protocol in Developing RMI Applications for Oracle WebLogic Server.

Note:

Although the WebLogic full client requires the largest JAR file among the various clients, it has the most features and is faster and more scalable than IIOP clients. The same JAR that provides the T3 protocol support also provides IIOP support.

A WebLogic full client:

  • Requires the wlfullclient.jar in your classpath.

  • Uses an URL in the form of t3://ip address:port for the initial context.

  • Is faster and more scalable than IIOP clients.

  • Supports most WebLogic Server-specific features.

  • Supports WebLogic Server clustering.

  • Supports most JavaEE features.

  • Supports WebLogic JMS, JMS SAF clients, and JMS C clients.

  • Uses Oracle WebLogic's T3/T3S protocol for Remote Method Invocation (RMI), including: RMI over HTTP (HTTP tunneling) and RMI over HTTPS (HTTP Tunneling over SSL). To understand WebLogic T3 communication, see Using WebLogic RMI with T3 Protocol in Developing RMI Applications for Oracle WebLogic Server.

Limitations and Considerations when Using the WebLogic Full Client

Understand the limitations and considerations while using WebLogic full client.

Consider the following when using the WebLogic full client:

  • Not all functionality available with weblogic.jar is available with the wlfullclient.jar. For example, wlfullclient.jar does not support Web Services, which requires the wseeclient.jar. Nor does wlfullclient.jar support operations necessary for development purposes, such as ejbc, or support administrative operations, such as deployment, which still require using the weblogic.jar.

  • In WebLogic Server 12.1.3 and higher releases, the WebLogic Full Client implements the JDK StAX parser which does not perform validation during rim RTD.xml parsing. In prior WebLogic Server releases, the WebLogic Full Client used the WebLogic StAX parser, which included validation for rim RTD.xml parsing.

Developing a WebLogic Full Client

Learn how to develop a WebLogic full client.

Creating a basic WebLogic full client consists of the following:

  1. Generate the wlfullclient.jar file for client applications using the JarBuilder tool. See Using the WebLogic JarBuilder Tool.

  2. Obtain a reference to the remote object.

    1. Get the initial context of the server that hosts the service using a T3 URL.

    2. Obtain an instance of the service object by performing a lookup using the initial context. This instance can then be used just like a local object reference.

  3. Call the remote objects methods.

Sample code to for a simple WebLogic full client is provided in Example 3-1.

Example 3-1 Simple WebLogic Full hello Client

package examples.rmi.hello;

import java.io.PrintStream;
import weblogic.utils.Debug;
import javax.naming.*;
import java.util.Hashtable;

/**
* This client uses the remote HelloServer methods.
*
* @author Copyright (c) Oracle. All Rights Reserved.
*/
public class HelloClient {

private final static boolean debug = true;

/**
* Defines the JNDI context factory.
*/
public final static String JNDI_FACTORY="weblogic.jndi.WLInitialContextFactory";

int port;
String host;

   private static void usage() {
   System.err.println("Usage: java examples.rmi.hello.HelloClient " +
      "<hostname> <port number>");
   System.exit(-1);
  } 

   public HelloClient() {}
   public static void main(String[] argv) throws Exception {
      if (argv.length < 2) {
      usage();
    }
   String host = argv[0];
   int port = 0;
   try {
      port = Integer.parseInt(argv[1]);
      }
   catch (NumberFormatException nfe) {
      usage();
      }
   try {

    InitialContext ic = getInitialContext("t3://" + host + ":" + port);

      Hello obj = 
        (Hello) ic.lookup("HelloServer");
      System.out.println("Successfully connected to HelloServer on " +
        host + " at port " +
        port + ": " + obj.sayHello() );
      }
   catch (Throwable t) {
   t.printStackTrace();
      System.exit(-1);
   }

  }

   private static InitialContext getInitialContext(String url)
     throws NamingException
   {
   Hashtable env = new Hashtable();
   env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
   env.put(Context.PROVIDER_URL, url);
   return new InitialContext(env);
   }
}

Communicating with a Server in Admin Mode

To communicate with a server instance that is in admin mode, you need to configure a communication channel by setting the following flag on your client: -Dweblogic.AdministrationProtocol=t3.

Running the WebLogic Full Client in a Non-Forked VM

If the WebLogic full client is running in a non-forked VM, for example by means of a <java> task invoked from an Ant script without the fork=true attribute, you might get an error.

The error generated is : java.lang.SecurityException: The provider self-integrity check failed. This error is caused by the self-integrity check that is automatically performed when the RSA Crypto-J library is loaded. (The Crypto-J library, cryptoj.jar, is in the wlfullclient.jar manifest classpath.)

This self-integrity check failure occurs when the client is started in a non-forked VM and it uses the Crypto-J API, either directly or indirectly, as in the following situations:

  • The client invokes the Crypto-J library directly.

  • The client attempts to make a T3S connection, which triggers the underlying client SSL implementation to invoke the Crypto-J API.

When the self-integrity check fails, further invocations of the Crypto-J API fail. To prevent this error from occurring, always set the fork attribute to true when running the full client in a <java> task that is invoked from an Ant script.

For more information about the self-integrity check, see "How a Provider Can Do Self-Integrity Checking" in How to Implement a Provider in the Java™ Cryptography Architecture, available at the following URL:

http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/HowToImplAProvider.html#integritycheck