|
|
This topic includes the following sections:
CORBA has two types of exceptions: standard system exceptions, which are fully specified by the OMG, and user exceptions, which are defined by the individual application programmer. CORBA exceptions differ slightly from Java exception objects, but those differences are largely handled in the mapping from IDL to Java.
Topics in this section include:
Exceptions
To specify an exception in IDL, the interface designer uses the raises keyword. This is similar to the throws specification in Java. When you use the exception keyword in IDL, you create a user-defined exception. The standard system exceptions need not (and cannot) be specified this way.
CORBA defines a set of standard system exceptions, which are generally raised by the ORB libraries to signal systemic error conditions including:
Differences Between CORBA and Java Exceptions
System Exceptions
All IDL operations can throw system exceptions when invoked. The interface designer need not specify anything to enable operations in the interface to throw system exceptions; the capability is automatic.
This makes sense because no matter how trivial an operation's implementation is, the potential of an operation invocation coming from a client that is in another process, and perhaps (likely) on another machine, means that a whole range of errors is possible.
Therefore, a CORBA client should always catch CORBA system exceptions. Moreover, developers cannot rely on the Java compiler to notify them of a system exception they should catch, because CORBA system exceptions are descendants of java.lang.RuntimeException
.
All CORBA system exceptions have the same structure:
exception <SystemExceptionName> { // descriptive of error System exceptions are subtypes of java.lang.RuntimeException
through org.omg.CORBA.SystemException
:
java.lang.Exception All CORBA system exceptions have a minor code field, a number that provides additional information about the nature of the failure that caused the exception. Minor code meanings are not specified by the OMG; each ORB vendor specifies appropriate minor codes for that implementation. For a description of minor codes thrown by the Java ORB, see Minor Code Meanings.
All CORBA system exceptions have a completion status field which indicates the status of the operation that threw the exception. The completion codes are:
System Exception Structure
unsigned long minor; // more detail about error
CompletionStatus completed; // yes, no, maybe
}
|
+--java.lang.RuntimeException
|
+--org.omg.CORBA.SystemException
|
+--BAD_PARAM
|
+--//etc. Minor Codes
Completion Status
The object implementation has completed processing prior to the exception being raised.
The object implementation was not invoked prior to the exception being raised.
The status of the invocation is unknown.
CORBA user exceptions are subtypes of java.lang.Exception through org.omg.CORBA.UserException:
java.lang.Exception Each user-defined exception specified in IDL results in a generated Java exception class. These exceptions are entirely defined and implemented by the programmer.
Every system exception has a "minor" field that allows CORBA vendors to provide additional information about the cause of the exception. The table below lists the minor codes of Java IDL's system exceptions, and describes their significance.
User Exceptions
|
+--org.omg.CORBA.UserException
|
+-- Stocks.BadSymbol
|
+--//etc. Minor Code Meanings
Table 4-1 ORB Minor Codes and Their Meanings
Table 4-2 Name Server Minor Codes and Their Meanings
Before a Java client or Java joint client/server can use CORBA objects, it must initialize itself by:
Initializations
Before it can create or invoke a CORBA object, an applet or client application must first create an ORB object. By creating an ORB object, the applet or application introduces itself to the ORB and obtains access to important operations that are defined on the ORB object.
Applets and applications create ORB instances slightly differently, because their parameters, which must be passed in the ORB.init() call, are arranged differently.
(For more information on initializing the ORB, see the CORBA ORB in the Java Programming Reference in the WebLogic Enterprise online documentation.)
This code fragment shows how an application might create an ORB:
import org.omg.CORBA.ORB; An applet creates an ORB like this:
import org.omg.CORBA.ORB; Some Web browsers have a built-in ORB. This can cause problems if that ORB is not entirely compliant. In this case, special steps must be taken to initialize the Java IDL ORB specifically. For example, because of missing classes in the installed ORB in Netscape Communicator 4.01, an applet displayed in that browser must contain code similar to the following in its init()
method:
import java.util.Properties; For both applications and applets, the arguments for the initialization method are:
Creating an ORB Object
Creating an ORB for an Application
public static void main(String args[])
{
try{
ORB orb = ORB.init(args, null);
// code continues Creating an ORB for an Applet
public void init() {
try {
ORB orb = ORB.init(this, null);
// code continues
import org.omg.CORBA.*;
public class MyApplet extends java.applet.Applet {
public void init()
{
// Instantiate the Java IDL ORB, passing in this applet
// so that the ORB can retrieve the applet properties.
Properties p = new Properties();
p.put("org.omg.CORBA.ORBClass", "com.sun.CORBA.iiop.ORB");
p.put("org.omg.CORBA.ORBSingletonClass","com.sun.CORBA.idl.ORBSingleton");
System.setProperties(p);
ORB orb = ORB.init(args, p);
...
}
} Arguments to ORB.init()
Provides the ORB access to the application's arguments or applet's parameters.
A java.util.Properties object.
The first value found for a particular property is the value used by the init() operation. If a configuration property cannot be found in any of these places, the init() operation assumes an implementation-specific value for it. For maximum portability among ORB implementations, applets and applications should explicitly specify configuration property values that affect their operation, rather than relying on the assumptions of the ORB in which they are running.
BEA WLE uses the Sun Microsystem Java virtual machine, which adds -D command line arguments to it. Other Java virtual machines may or may not do the same.
Currently, the following configuration properties are defined for all ORB implementations:
The name of a Java class that implements the org.omg.CORBA.ORB interface. Applets and applications do not need to supply this property unless they must have a particular ORB implementation. The value for the Java IDL ORB is com.sun.CORBA.iiop.ORB .
The name of a Java class that implements the org.omg.CORBA.ORB interface. This is the object returned by a call to orb.init() with no arguments. It is used primarily to create typecode instances than can be shared across untrusted code (such as unsigned applets) in a secured environment.
Applet parameters should specify the full property names. The conventions for applications differ from applets so as not to expose language-specific details in command-line invocations.
To invoke a CORBA object, an applet or application must have a reference for it. There are three ways to get a reference for a CORBA object:
Obtaining Initial Object References
The first technique, converting a stringified reference to an actual object reference, is ORB-implementation independent. Regardless of which Java ORB an applet or application runs on, it can convert a stringified object reference. However, it is up to the applet or application developer to:
Stringified Object References
The following fragment shows how a server converts a CORBA object reference to a string:
org.omg.CORBA.ORB orb = // get an ORB object This code fragment shows how a client converts the stringified object reference back to an object:
org.omg.CORBA.ORB orb = // get an ORB object If you do not use a stringified reference to get an initial CORBA object, you use the ORB itself to produce an initial object reference.
The WLE Bootstrap object defines an operation called resolve_initial_references()
that is intended for bootstrapping object references into a newly started application or applet. The operation takes a string argument that names one of a few recognized objects; it returns a CORBA Object, which must be narrowed to the type the applet or application knows it to be.
Using the Bootstrap object, you can obtain four different object references (SecurityCurrent, TransactionCurrent, FactoryFinder, and InterfaceRepository). The object of concern to us here is the FactoryFinder.
The FactoryFinder interface provides clients with one object reference that serves as the single point of entry into the WLE domain. The FactoryFinder object is used to obtain a specific factory object, which in turn can create the needed objects.
For more information on how to use the Bootstrap object, see the Java Bootstrap Object Programming Reference in the WebLogic Enterprise online documentation.
The FactoryFinder interface provides clients with one object reference that serves as the single point of entry into the WLE domain. The WLE NameManager provides the mapping of factory names to object references for the FactoryFinder. Multiple FactoryFinders and NameManagers together provide increased availability and reliability. Mapping across multiple domains is supported.
Note:
The NameManager is not a naming service, such as CORBAservices Naming Service, but is merely a vehicle for storing registered factories.
The FactoryFinder interface and the NameManager are a mechanism for registering, storing, and finding objects. In the WLE environment, you can:
org.omg.CORBA.Object obj = // create the object reference
String str = orb.object_to_string(obj);
// make the string available to the client
String stringifiedref = // read string
org.omg.CORBA.Object obj = orb.string_to_object(stringifiedref); Getting References from the ORB
The FactoryFinder Interface
For more information about how to use the WLE FactoryFinder Interface, see the FactoryFinder Interface in the CORBA Java Programming Reference in the WebLogic Enterprise online documentation.
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|