Set - 4

Question 11 :

How do an RMI-IIOP application and an existing CORBA object interoperate?

Answer :

If the existing CORBA object has its remote interfaces defined originally in CORBA IDL, then interoperability is not possible. RMI-IIOP applications can interoperate with other CORBA objects only when their remote interfaces are originally defined as Java RMI interfaces.
For example, to interoperate between an RMI-IIOP client and a C++ object you need to:
1. Define the remote interface of the object in Java as an RMI interface.
2. Run rmic -iiop against the interface to produce the stub for your RMI-IIOP client.
3. Run rmic -idl against the interface to produce IDL compatible with the RMI interface.
4. Run a C++ stub compiler against the IDL file to produce the C++ skeleton for your C++ server object


Question 12 :

What is the function of T3 in WebLogic Server?

Answer :

T3 provides a framework for WebLogic Server messages that support for enhancements. These enhancements include abbreviations and features, such as object replacement, that work in the context of WebLogic Server clusters and HTTP and other product tunneling.
T3 predates Java Object Serialization and RMI, while closely tracking and leveraging these specifications. T3 is a superset of Java Object. Serialization or RMI; anything you can do in Java Object Serialization and RMI can be done over T3.
T3 is mandated between WebLogic Servers and between programmatic clients and a WebLogic Server cluster. HTTP and IIOP are optional protocols that can be used to communicate between other processes and WebLogic Server. It depends on what you want to do. For example, when you want to communicate between
* A browser and WebLogic Server-use HTTP
* An ORB and WebLogic Server-IIOP.


Question 13 :

How can I debug the Java code that I have running in WebLogic Server?

Answer :

You can use tools such as WebGain, JBuilder, NetBeans and JDB that rely on the Java Platform Debugger Architecture (JPDA) to debug your Java code running in WebLogic Server.
JPDA is integrated in the Java 2 Platform, Standard Edition (J2SE) SDK 1.3 on all platforms and SDK 1.2.2 for Linux. There is a download available from Sun to add JPDA support to the J2SE SDK 1.2.2 on Solaris and Microsoft Window platforms. If you are using J2SE SDK 1.2.2 on these platforms you must first get this download.
To allow a debugger to attach to the virtual machine that WebLogic runs you have to start WebLogic in debug mode. In order to start WebLogic in debug mode using a Sun virtual machine follow these steps (start with step one only if using a Solaris platform):
1. If using a Solaris platform, change the LD_LIBRARY_PATH environment variable to prepend $JAVA_home/lib/sparc:
export LD_LIBRARY_PATH=$JAVA_home/lib/sparc:$LD_LIBRARY_PATH
2. Add the following parameters to the java command line (before the "weblogic.Server" string) that launches WebLogic server:
-Xdebug
-Xnoagent
-Xrunjdwp:transport=dt_socket
server=y
address=
suspend=n
-Djava.compiler=NONE

Note that with the Hotspot Performance engine the -Xnoagent and -Djava.compiler=NONE options are no longer required, but are accepted and ignored for compatibility reasons.
If server=y and no address parameter is supplied, WebLogic Server chooses the transport address and prints it to the standard output stream. So, if a line such as:
Listening for transport dt_socket at address: 46666
prints in your standard output stream when the server starts, the number 46666 is the port number to be supplied to your tool's remote debugger in order to attach it to WebLogic's virutal machine.


Question 14 :

How do I call a servlet with parameters in the URL?

Answer :

The usual format of a servlet parameter is a name=value pair that comes after a question-mark (?) at the end of the URL. To access these parameters, call the getParameter() method on the HttpServletRequest object, then write code to test the strings. For example, if your URL parameters are "func=topic," where your URL appears as:

http://www.myserver.com/myservlet?func=topic
then you could parse the parameter as follows, where "req" is the HttpServletRequest object:
String func = req.getParameter("func");
if (func.equalsIgnoreCase("topic")) {
. . . do some work
}


Question 15 :

How do I identify the document type of an XML document?

Answer :

If the XML document has a Public ID, then that is its document type. For example, if an XML document contains the following DOCTYPE declaration:
"http://foo.com/url/to/my/dtd">

then its document type is My public ID String.

If the DOCTYPE declaration does not contain a Public ID, but specifies a System ID, then the document type is the System ID. For example, in the following DOCTYPE declaration:

the document type is http://foo.com/url/to/my/dtd.
Note: The System ID is of the DTD, not of the XML document itself. It can, however, still be used as a way to identify the XML document.
If the XML document does not specify a DOCTYPE declaration, then the document type can be either the root element name or the namespace URI, if it has one.