BEA Weblogic Interview Questions & Answers

Download PDF

The Oracle 8 server generates an ORA-01002:fetch out of sequence error message when you use a FOR UPDATE statement with AUTOCOMMIT turned on (which is the default state when using JDBC). This is known to happen on Oracle 8.0 and 8.1 on Solaris and on Oracle 8.1 on Windows NT. If you turn AUTOCOMMIT off, you will not receive this error. Because this problem is due to a change in the Oracle 8 server, you should contact Oracle support for more information.

A system administrator can specify on which WebLogic Server(s) applications will run by specifying targets when configuring connection factories. Each connection factory can be deployed on multiple WebLogic servers.
Note: If you use the default connection factory, you have no control over the WebLogic server on which the connection factory may be deployed. If you would like to target a particular WebLogic server, create a new connection factory and specify the appropriate JMS server target(s).

If your WebLogic jDriver for Oracle application produces an SQLException such as:

java.sql.SQLException: ORA-12536: TNS: operation would block

You can look up an Oracle error by using the oerr command. For example, the description of error ORA-12536 can be found with the command:

> oerr ora 12536

To use Unicode codesets:
1. Install the appropriate codeset when you install Oracle. If you did not do this in the original installation, you will need to re-run the Oracle installer and install the proper codeset.
2. Define the NLS_LANG variable in the environment where the JDBC driver is running. Do this by assigning the proper codeset to NLS_LANG in the shell from where you start the WebLogic Server.
The Developers Guide has more information about internationalization support.

Yes. Use the setAttribute() method for SAX mode parsing and the getAttribute() method for DOM mode parsing. Using these methods in a Servlet, however, is a WebLogic-specific feature. This means that the Servlet may not be fully portable to other Servlet engines, so use the feature with caution.

The WL-Proxy-Client-Cert header can be spoofed (used) by any client which has direct access to WebLogic Server. WebLogic Server takes the certificate information from that header, trusting that is came from a secure source (the plug-in) and use that information to authenticate the user. In previous releases of WebLogic Server, the default behavior was to always trust that header. Now you need to explicitly define trust of the WL-Proxy-Client-Cert header. A new parameter clientCertProxy allows WebLogic Server to on the implicit trust of the certificate header. If you need an additional level of security, use a connection filter to limit all connections into WebLogic Server (therefore allowing WebLogic Server to only accept connections from the machine on which the plug-in is running).
The clientCertProxy parameter has been added to the HTTPClusterServlet and Web applications.
For the HTTPClusterServlet, add the parameter to the web.xml file as follows:
<context-param>
<param-name>clientCertProxy</param-name>
<param-value>true</param-value>
</context-param>

For Web applications, add the parameter to the web.xml file as follows:

ServletRequestImpl context-param
<context-param>
<param-name>weblogic.http.clientCertProxy</param-name>
<param-value>true</param-value>
</context-param>

You can also use this parameter in a cluster as follows:
<Cluster ClusterAddress="127.0.0.1" Name="MyCluster"
ClientCertProxyHeader="true"/>

If you want to run multiple instances, your servlet will have to implement the SingleThreadModel interface. An instance of a class that implements the SingleThreadModel interface is guaranteed not to be invoked by multiple threads simultaneously. Multiple instances of a SingleThreadModel interface are used to service simultaneous requests, each running in a single thread.
When designing your servlet, consider how you use shared resources outside of the servlet class such as file and database access. Because there are multiple instances of servlets that are identical, and may use exactly the same resources, there are still synchronization and sharing issues that must be resolved, even if you do implement the SingleThreadModel interface.

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:
<!DOCTYPE mydoc PUBLIC "My public ID String"
"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:
<!DOCTYPE mydoc SYSTEM "http://foo.com/url/to/my/dtd">
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.

a. In case of a MDB, developer needs to create a MessageListener class that utilizes a server-wide session pool.
b. WebLogic Server container provides standard EJB services to MDBs.
c. MDBs benefit from the write-once, deploy-anywhere paradigm of EJBs.
d. MDBs can be associated with multiple Messaging Queues or Topics unlike standard JMS.


Choices B and C are correct. A message-driven bean is a special kind of EJB that acts as a message consumer in the WebLogic JMS messaging system. As with standard JMS message consumers, message-driven beans receive messages from a JMS Queue or Topic, and perform business logic based on the message contents. EJB deployers create listeners to a Queue or Topic at deployment time, and WebLogic Server automatically creates and removes message-driven bean instances as needed to process incoming messages.
Because message-driven beans are implemented as EJBs, they benefit from several key services that are not available to standard JMS consumers. Most importantly, message-driven bean instances are wholly managed by the WebLogic Server EJB container. Using a single message-driven bean class, WebLogic Server creates multiple EJB instances as necessary to process large volumes of messages concurrently. This stands in contrast to a standard JMS messaging system, where the developer must create a MessageListener class that utilizes a server-wide session pool. Thus choice A is incorrect.
WebLogic Server provides standard EJB services to MDBs, such as security services and automatic transaction management. Thus choice B is correct.
Being implemented as EJBs, MDBS benefit from the write-once, deploy-anywhere quality of EJBs. Whereas a JMS MessageListener is tied to specific session pools, Queues, or Topics, message-driven beans can be developed independently of available server resources. Thus Choice C is also correct.
Its not that MDBs are always advantageous as compared to standard JMS consumers. One limitation of MDBs compared to standard JMS listeners is that a given MDB deployment can be associated with only one Queue or Topic. If your application requires a single JMS consumer to service messages from multiple Queues or Topics, you must use a standard JMS consumer, or deploy multiple message-driven bean classes. Thus Choice D is incorrect.

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

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.

You may see messages like these in the log file:
(Windows NT)
java.io.IOException Connection Reset by Peer
java.io.EOFException 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.

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

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 EntityContext interface. The getHomeHandle method is defined in the EJBHome interface.

a. beforeBegin
b. afterBegin
c. beforeCompletion
d. afterCompletion


Choices B, C and D are correct. A stateful session bean using container-managed transactions can implement the javax.ejb.SessionSynchronization interface to provide transaction synchronization notifications. This interface defines only 3 methods - afterBegin(), beforeCompletion() and afterCompletion().
The afterBegin() callback method is called when the bean becomes part of a transaction. It is called before the EJB Object delegates the business method invocation to the bean instance. If the transaction is committed, the bean will be notified through its beforeCompletion() method. If the transaction is rolled back, this method is not invoked. The afterCompletion() method is always invoked whether the transaction ended with a commit or a rollback. A is incorrect because beforeBegin is not a method defined in the SessionSynchronization interface.

You can add a startup script to your UNIX rc scripts to run WebLogic Server at UNIX boot time. Here is an example from an HP-UX 11 system, running under JDK 1.1. You need to supply the URL for your WebLogic Server and your system password. This file, wlstart, is placed in the /sbin/init.d directory and there is a link to it in the /sbin/rc2.d directory:

export SHLIB_PATH=
/home/user1/weblogic/lib/hpux11:/oracle/8.0.4/lib
export CLASSPATH=/home/user1/weblogic/classes:
/home/user1/weblogic/lib/weblogicaux.jar
export ORACLE_HOME=/oracle/8.0.4
export ORACLE_SID=DEMO
export ORACLE_TERM=vt100
export QAT=/home/user1/weblogic
cd $QAT
PATH=/sbin:/usr/sbin:/usr/bin:/opt/java/bin
export PATH
case $1 in
'start')
java -ms64m -mx64m -verbosegc weblogic.Server >
/home/user1/weblogic/server.out 2> #emp;
;;
'stop')
java weblogic.Admin URL shutdown system password
;;
*)
echo "usage: $0 {start|stop}"
;;
esac

You should work with your UNIX system administrator to set up scripts similar to this for your system.

You can configure a java.net socket to use SOCKS by setting a Java system property.

Choices:
a. Installer
b. Deployer
c. Bootstrap
d. Packager


Choices A and C are correct. To publish to a WebLogic Server, we can use the ZAC publish wizard. For this, the server must be running, and you will need to know a user and password that has permission to publish. You can also use the ZAC Publish Wizard to create a set of native programs - an installer and a bootstrap - for various operating systems that become part of a published Java application.
The installer program is a native executable that installs your published Java program on the local machine. It doesn't require a Java environment itself, so it can run out-of-the-box in the native OS. The bootstrap is also a native program; the user runs the bootstrap to invoke the published application. The bootstrap takes care of monitoring for updates, downloading and updating the user's application, and other administrative ZAC functions.

a. JTA
b. JNDI
c. JMS
d. JTS
e. JMX


Choice B is correct. WebLogic Server supports the javax.transaction package and the javax.transaction.xa package, which implement the Java Transaction API (JTA) for Java applications.
javax.transaction.UserTransaction provides an interface to the transaction manager that allows the application developer to manage the scope of a transaction explicitly. The client application uses JNDI to obtain an object reference to the UserTransaction object for the WebLogic Server domain.
The code used by the client is given.
UserTransaction ut=(UserTransaction)jndicontext.lookup("javax.transaction.UserTransaction")
If a bean needs a reference to the UserTransaction object, it obtains it from the EJBContext as given.
UserTransaction ut=ejbContext.getUserTransaction()

You can enable debugging for the messaging bridge using either of the followings methods:

* Add the following lines to your WebLogic start script (before the weblogic.Server line):
-Dweblogic.Debug.DebugMessagingBridgeStartup=true
-Dweblogic.Debug.DebugMessagingBridgeRuntime=true
* Add the following statements to the ServerDebug entry in your configuration file (config.xml) for the server that the messaging bridge is running on:
DebugMessagingBridgeStartup="true"
DebugMessagingBridgeRuntime="true"
Once debugging is enabled for the messaging bridge, the debugging messages are sent to the server log by default. However, if you want them to appear in the Administration Console, add "DumpToConsole" to the statements show above. For example:
-Dweblogic.Debug.DebugMessagingBridgeStartupDumpToConsole=true

Leave the Adapter Classpath field blank when connecting to source and target destinations that are both running on release 6.1 or later. When connecting to either a source or target destination that is running on release 6.0 or earlier, the Adapter Classpath field must indicate the location of the classes for the earlier WebLogic Server release. When connecting to a third-party JMS provider, the bridge destination must supply the provider's CLASSPATH in the WebLogic Server CLASSPATH.

There are some additional configuration requirements for the messaging bridge to handle transactions between WebLogic domains:

* The supported adapters are located in the WL_HOMElib directory. For the Exactly-once QOS, the transaction adapter, jms-xa-adp.rar, must be deployed in the release 6.1 domain where the bridge is running, via the select Deployments —> Applications node on the console.
* This jms-xa-adp.rar adapter must also be identified in the Adapter JNDI Name attribute as eis.jms.WLSConnectionFactoryJNDIXA on the JMS Bridge Destination —> Configuration tab for both the source and target bridge destinations.
* For WebLogic JMS, verify that you are using the transactional XAConnectionFactory for the queue or topic destinations mapped to both the source and target bridge destinations. To verify this, the following attributes must be set on the JMS —> Connection Factory —> Configuration —> Transactions console tab or in the configuration file (config.xml):
UserTransactionsEnabled=true
XAConnectionFactory=true
* For third-party JMS vendors, verify that you are using a transactional connection factory for the destinations mapped to the source and target bridge destinations.

Either an error occurred when configuring the source bridge destination parameters, or the actual source destination is not running and cannot communicate with the messaging bridge.

* Verify whether the bridge's source destination is correctly configured, by making sure that the following fields on the JMS Bridge Destination —> Configuration —> General console page have been properly completed:

o Connection URL—this must be the URL of the JNDI provider used to look up the connection factory and actual destination.
o Destination JNDI Name—this must be the JNDI name of the actual destination mapped to the source bridge destination.
o Connection Factory JNDI Name—this must be the connection factory used to create a connection for the actual destination mapped to the source bridge destination.
o User Name/Password—make sure that this user ID has permission to access the actual source destination.
* Verify that the actual source queue or topic destination mapped to the source bridge destination is running and healthy, as follows:
o Is the WebLogic Server instance hosting the source destination running?
o Is the JMS server hosting the source destination correctly deployed?

Note: This troubleshooting scenario for correcting a source bridge destination connection failure also applies to target bridge destinations.

No. The message is asynchronously received outside a transaction and there is no J2EE API to then associate the message with a transaction.
The only reason this works for WebLogic Server JMS is that we have defined a WebLogic Server extension interface that has a method to associate a message with a transaction. This interface, MDBTransaction, is defined in news://newsgroups.bea.com/3b3a009b$1@newsgroups.bea.com. It has one method, associateTransaction(), that takes a javax.jms.Message parameter. This message must be associated with the transaction. We are hoping that other JMS vendors interested in integrating with WebLogic Server will implement this interface.
Another approach called source managed transactions, would be for there to be an API to tell the JMS provider to start a transaction on your behalf before delivering the message to an asynchronous consumer. This API doesn't exist in J2EE either. Even if there were such a provision, few non-WLS JMS providers can begin and drive such a transaction by themselves.
The current solution is to move all messages from the foreign destination to a WebLogic Server JMS destination (within a transaction if the foreign JMS provider supports it) and have that WebLogic Server JMS destination drive the MDB transactionally (using the WLS JMS special interface). Currently, the messages can be moved between providers using code similar to that described in the "Using Foreign JMS Providers With WebLogic Server" white paper. This code could be contained in a startup class that starts a thread and does the following:
while (true) {
start a transaction
receive a message synchronously with timeout
if timed_out { rollback and continue }
do the work
commit the transaction }

Doing a synchronous receive will have a problem in that the transaction may time out before the message is received. You can do the receive with a specified timeout, allowing enough time left in the transaction to complete the work. If the receive fails, roll back the transaction and try again. It is also not as efficient as MDBs since it does a synchronous instead of asynchronous receive (it ties up threads). Also, if you get a lot of timeouts, you will be burning more CPU.
Eventually, WLS JMS will provide a bridge to handle this message passing out-of-the box.
With any of these approaches, the XAResource must be registered with the Transaction Manager (this is done automatically for WebLogic Server JMS).