Which is the only method defined in the
javax.ejb.Handle interface?
a. getEJBhome
b. getEJBObject
c. getPrimaryKey
d. gethomeHandle
Choice B is correct. The Handle is a serializable
reference to the EJBObject. The EJBObject.getHandle()
method returns a Handle object. The Handle allows us to
recreate an EJB object remote reference that points to
the same type of session bean or the same unique bean
that the handle came from.
The Handle interface specifies only one method,
getEJBObject(). Calling this method returns the EJB
Object from which the handle was created. After getting
the object back, we can narrow or cast it to the
appropriate remote interface type. The getEJBhome method
is defined in the homeHandle interface and the
getPrimaryKey method in the Entity Context interface. The
gethomeHandle method is defined in the EJBhome
interface.
In CORBA, which of the following files generated by the
"idltojava" compiler must be compiled before running the
server application?
a. Only The Holder Classes
b. Only The Helper and Holder Classes
c. The implementation class(es) written by the user to
provide body to the methods defined in the interface
class
d. All idltojava generated files (stubs, skeletons,
helper, holder and interface classes)
Choice C and D are correct. The Helper class (a final
class) provides auxiliary functionality, notably the
narrow() method required to cast CORBA object references
to their proper types. The Holder class provides
operations for out and in out arguments, which CORBA has
but which do not map easily to Java's semantics. The
server application cannot be compiled successfully until
the implementation class(es) has/have been written and
compiled. All the other generated files however must be
compiled to form '.class' files from the '.java' files.
Thus all the implementation classes written by the user
and all the "idltojava" generated files must be complied
to run the CORBA Server.
Considering the code below, which of the lines of code
(given in the choices) should be placed at line 4 to
make this JSP prints "My score is : 100"? Please ignore
the line numbers for the purpose of validity of the JSP
code.
1:
2:
3:
My Progress Report
4:
5: <% score++; %>
6: <%= "My score is : " + score %>
7:
8:
a. <%! int score = 99; %>
` b. <% int score; %> `
c. <%@ int score = 99; %>
` d. < int score = 99; />
A is the correct choice. The above JSP will work on
declaring and initializing the variable score. The
syntax for declaring and initializing a variable in JSP
is as follows:
<%! variable=variable_value ; %>
Thus A is the correct choice. The <%@ ... %> tag is used
to declare directives like include directive. Thus
choice C is incorrect. The <% ... %> code is used to
insert scriptlet (lines of code in java) like the one
at line 5. The code written inside the scriptlet becomes
part of the service() method of the generated Servlet.
Thus 'score' becomes the local variable of the service
method. And for this JSP to compile properly, the
variable 'score' should have been initialized. If "<%
int score; %>" is replaced by "<% int score=99; %>" ,
the choice B would also be correct. In the present
scenario, the choice B will give compilation error
saying "Variable score may not have been initialized".
Choice D is incorrect as it's not a valid tag.
How do I increase WebLogic Server memory?
Increase the allocation of Java heap memory for WebLogic
Server. (Set the minimum and the maximum to the same
size.) Start WebLogic Server with the -ms32m option to
increase the allocation, as in this example:
$ java ... -ms32m -mx32m ...
This allocates 32 megabytes of Java heap memory to
WebLogic Server, which improves performance and allows
WebLogic Server to handle more simultaneous connections.
You can increase this value if necessary.
What causes Java.io exceptions in the log file?
You may see messages like these in the log file:
(Windows NT)
java.io.IOException Connection Reset by Peer
java.io.IOException Connection Reset by Peer
(Solaris)
java.io.Exception: Broken pipe
These messages occur when you are using servlets. A
client initiates an HTTP request, and then performs a
series of actions on the browser:
1. Click Stop or enter equivalent command or keystrokes
2. Click Refresh or enter equivalent command or
keystrokes
3. Send a new HTTP request.
The messages indicate that WebLogic Server has detected
and recovered from an interrupted HTTP request.
Java-CORBA integration: RMI-IIOP or Java IDL?
It is important to understand the distinction between
these two ways of integrating Java with CORBA.
RMI-IIOP is for Java programmers who want to program to
the RMI interfaces but use IIOP as the underlying
transport. RMI-IIOP provides interoperability with other
CORBA objects implemented in various languages, but only
if all the remote interfaces are originally defined as
Java RMI interfaces. It is of particular interest to
programmers using Enterprise JavaBeans (EJBs), because
the remote object model for EJB is RMI-based.
Java IDL is for CORBA programmers who want to program in
Java based on interfaces defined in CORBA IDL. This is
"business as usual" CORBA programming, supporting Java
in exactly the same way as other languages like C++ or
COBOL.
How do an RMI-IIOP application and an existing CORBA
object interoperate?
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
Page Numbers :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
