BEA Weblogic

a. Not possible.

b. Store the reference to the EJB instance as an instance variable of Servlet class.

c. Store the reference to the EJB instance as a local variable of Servlet class.

d. Make the Servlet client to be remote instead of internal to WebLogic server.

Choice C is the correct choice. An instance of a stateful session EJB can be accessed from only one client virtual machine at a time. Multiple client threads from the same virtual machine can access the same instance of a stateful session EJB, but they must do so in a serial fashion. If a client-invoked business method is in progress on an instance when another client-invoked call, from the same or different client, arrives at the same instance of a stateful session bean class, the container may throw the java.rmi.RemoteException to the second client , if the client is a remote client, or the javax.ejb.EJBException, if the client is a local client. Thus choice D is incorrect.

To avoid any exception, each Servlet should store a reference to a particular EJB instance in a local variable of the Servlet's service() method. Please note that variables local to methods like service(), doGet(), doPost() are not shared between different requests and are automatically thread safe. Thus choice C is correct. An instance variable unlike local variable is shared. Thus Choice B is incorrect.

An implication of this rule is that an application cannot make loop back calls to a session bean instance.

This restriction does not apply to a stateless session bean because the container routes each request to a different instance of the session bean class.

On Windows, start WLS 6.X by selecting Start -< Programs -< BEA WebLogic E-Business Platform -< WebLogic Server 6.X -< Start Default Server and enter the administrator password.

On Windows, to configure JMS, start the console by selecting Start -< Programs -< BEA WebLogic E-Business Platform -< WebLogic Server 6.X -< Start Default Console.

1. In the console tree view on the left, select JMS.

2. If you want persistent messages, first create a Store - Select Stores. In the window on the right, Select Create a new JMSFile Store for a file store, give it a name, give it a directory, select create. If you want a JDBCStore, you first need to create a JDBC connection pool by selecting JDBC in the tree view, Connection Pools, create a new JDBC Connection Pool. Select Targets, select a Target server, select the arrow that points to the right and select Apply. Then go back to Stores, Create a new JMSJDBCStore.

3. If you want to use a template, first create a Template - Select Templates. You need a template to create temporary queues. Select Create a new JMS Template, give it a name, select create, then you can move to the Thresholds &Quotas tab or the Override tab. Select Apply when done with your changes.

4. Select Servers. Select Create a new JMSServer, give it a name, select a Store if you created one, select a template if you created one, Select Create. Now you can move to the other tabs, make changes, select Apply. In particular, you must select Targets, select a Target server, select the arrow that points to the right, and select Apply. This is the server on which JMS will boot.

5. Create Destinations - from the tree view in the left panel, select the + in front of JMS, select the + in front of Servers, select the + in front of your server, select Destinations, Select Create a new JMSQueue or Create a new JMSTopic, fill in the first page and Select Create, then you can select, fill in, and Apply other tabs.

6. Create Connection Factories - on left tree view, open JMS. Select Connection Factory. Select Create a new JMS Connection Factory on the right panel. Type in the name and JNDI name. Select Create (lower right hand corner). Select the Targets tab. Select the name of the server on which you want to deploy the connection factory. Select the arrow pointing to the right - the server moves to chosen. Then select Apply (lower right hand corner).

WebLogic JMS supports cluster-wide, transparent access to destinations from any server in the cluster. A system administrator can establish cluster-wide, transparent access to destinations from any server in the cluster by configuring multiple connection factories and using targets to assign them to WebLogic Servers. Each connection factory can be deployed on multiple WebLogic Servers.

The application uses the Java Naming and Directory Interface (JNDI) to look up a connection factory and create a connection to establish communication with a JMS server. Each JMS server handles requests for a set of destinations. Requests for destinations not handled by a JMS server are forwarded to the appropriate server.

You can configure multiple JMS servers on the various nodes in the cluster as long as you give them different names. You can assign destinations to the various JMS servers.

One problem to be aware of is the propagation delay in replicating entries in JNDI. If you have an MDB deployed on one node but reference a destination on another node, the deployment may fail with a javax.naming.NamingException exception. The problem occurs because the server is not synced up to the JNDI from the remote server (JMS server) yet, so the JNDI lookup of destination as part of MDB deployment will fail. One workaround is for each MDB to reference a local destination. Another approach is deploy the MDBs after the server boots (plus a delay for JNDI propagation). To get around losing messages before the MDB is deployed, use durable subscribers. This problem is fixed for MDBs in WLS 6.1, where the MDB will be deployed and reconnection will be retried until the destination is available. Note that this is still a problem for EJBs in general that try to reference a non-local JMS destination.

a. max-beans-in-free-pool

b. max-beans-in-cache

c. max-beans-in-memory

d. max-stateless-beans-in-cache

Choice A is correct. WebLogic Server maintains a free pool of EJBs for every stateless session bean class. The max-beans-in-free-pool element defines the size of this pool. By default, max-beans-in-free-pool has no limit; the maximum number of beans in the free pool is limited only by the available memory.

When EJBs are created, the session bean instance is created and given an identity. When the client removes a bean, the bean instance is placed in the free pool. When you create a subsequent bean, you can avoid object allocation by reusing the previous instance that is in the free pool. So the max-beans-in-free-pool element can improve performance if EJBs are frequently created and removed. Keeping this parameter too high uses extra memory and keeping it too low causes unnecessary object creation.

WebLogic Server allows you to configure the number of active beans that are present in the EJB cache (the in-memory space where beans exist). The max-beans-in-cache element specifies the maximum number of objects of this class that are allowed in memory. When max-bean-in-cache is reached, WebLogic Server passivates some EJBs that have not been recently used by a client. Choices C and D are not valid properties.

a. Two stateful session beans are identical if their data attributes are identical.

b. Two stateful session beans are identical if their session contexts are equal.

c. Two stateless session beans are identical if they are of the same type.

d. Two stateless session beans are identical if their session contexts are equal.

e. Two entity beans are identical if they have same primary key but different home interface.

f. Two entity beans are identical if they have different primary key but same home interface.

B and C are correct. Since the stateful session beans maintain the conversational state of the clients, they are identical when their session contexts are equal. Two stateful session beans may have identical data attributes, but if the session contexts are different they are not identical. Thus choice A is incorrect and B is correct. Since stateless beans do not retain the conversational state, they are considered identical if they are of the same type. Thus choice C is correct.

If two entity objects have the same home interface and primary key, they are considered identical. The EJB specification does not mention object equality based on the = = operator. Also, if you compare two object references using the Java API, Object.equals(Object obj), the result is unspecified. The only way to compare object equality is through the isIdentical (EJBObject) API. Thus choice E and F are incorrect.

Destination keys are used to define the sort order for a specific destination. Destination keys can be message header or property fields. For a list of valid message header and property fields, refer to the Programming WebLogic JMS.

Queues can be sorted in ascending or descending order based on the destination key. A destination is considered to be first-in-first-out if a destination key is defined as ascending for the JMSMessageID message header field, and last-in-first-out if defined as descending. The key defined for the JMSMessageID header field, if specified, must be the last key defined in the list of keys.

You can define multiple destination keys to sort a destination.

a. The amount of time that WebLogic Server waits between receiving chunks of data in an HTTP POST.

b. The total amount of time that WebLogic Server spends receiving HTTP POST data.

c. The time spent by WebLogic server to post data to other servers in the cluster.

d. The number of bytes of data received in a POST from a single request.

Choice B is correct. Web servers may face denial-of-service attacks, which is usually carried out by sending huge amounts of data in an HTTP POST method. You can set three attributes in WebLogic Server that help prevent this type of attack. These attributes are set in the console, under Servers or virtual hosts. You can limit the amount of time that WebLogic Server waits between receiving chunks of data in an HTTP POST by setting the attribute PostTimeoutSecs.

The MaxPostTimeSecs attribute limits the total amount of time that WebLogic Server spends receiving post data. If this limit is triggered, a PostTimeoutException is thrown and a message is sent to the server log. MaxPostSize attribute limits the number of bytes of data received in a POST from a single request. If this limit is triggered, a MaxPostSizeExceeded exception is thrown and a message is sent to the server log.

a. WebLogic Server allows transactions to be terminated only by the client that created the transaction.

b. WebLogic Server does not support multithreaded transactional clients.

c. A client or a server object cannot invoke methods on an object that is participating in another transaction.

d. WebLogic server supports Nested Transactions

Choices A and C are correct. WebLogic Server provides a Transaction Service that supports transactions in EJB and RMI applications. WebLogic Server allows transactions to be terminated only by the client that created the transaction. WebLogic Server implements the flat transaction model. Nested transactions are not supported.

WebLogic Server supports multithreaded transactional clients. Clients can make transaction requests concurrently in multiple threads. In WebLogic Server, a client or a server object cannot invoke methods on an object that is infected with (or participating in) another transaction. The method invocation issued by the client or the server will return an exception. Also in WebLogic Server, clients using third-party implementations of the Java Transaction API (for Java applications) are not supported.

a. Servlets, JSPs, EJBs, RMI objects, and Java applications use the Java Authentication and Authorization Service to authenticate WebLogic Server.

b. The default security realm in WebLogic Server is the File realm.

c. The default authentication scheme for WebLogic Server is two-way authentication.

d. An Administration Server may contain configuration information for one WebLogic Server or a cluster of WebLogic servers.

Choice C is correct because it is not true about the security in WebLogic server. A,B and D are true. Servlets, JSPs, EJBs, RMI objects, and Java applications use the Java Authentication and Authorization Service to authenticate WebLogic Server. JAAS is a standard extension to the Java 2 Software Development Kit. The authentication component of JAAS provides the ability to reliably and securely maintain client identity, regardless of whether the code is running as a Java application, a JSP, an EJB, an RMI object or a servlet.

In WebLogic Server, JAAS is layered over the existing Security Service Provider Interface (SPI) allowing the continued use of realm-based authorization. The default security realm in WebLogic Server is the File realm. When WebLogic Server is started, the File realm creates User, Group, and ACL objects from properties defined through the Administration Console in WebLogic Server and stored in the fileRealm.properties file. The File realm is designed for use with 1,000 or fewer users, for more no of users, an alternate security realm should be used. In WebLogic Server, an Administration Server is a WebLogic Server that functions as the central source of all configuration information. An Administration Server may contain configuration information for one WebLogic Server or a cluster of WebLogic servers.

"CORBA" support means many things to many people. It often means simply IIOP /ORB support and not much on CORBA services. WebLogic supports CORBA in multiple ways.

First, Java clients can tunnel through a CORBA environment to WebLogic Server. We call this "IIOP tunneling," and it is intended for use with applets coming through an IIOP firewall, such as the IONA Wonderwall product. This is a Java-to-Java model riding over an IIOP communications framework.

WebLogic RMI over IIOP provides RMI services for many clients (including CORBA clients) over IIOP.

WebLogic Enterprise Connectivity enables you to create IIOP connection pools to a BEA WebLogic Enterprise System, allowing you to execute WebLogic Enterprise CORBA objects from WebLogic Server servlets and Enterprise JavaBeans.

Why do I get "NoClassDefFound"/"Too Many Open files"messages on Solaris?

Problem: When I am using WebLogic Server on Solaris and try to run my application, I get a "NoClassDefFound" error, although the class causing the error does exist and is in the right directory. In fact, there are other classes in the same directory that are getting loaded. I also get a "Too many open files" error.

We have seen this situation when the user account runs out of file descriptors. On Solaris, each user account has a certain limited number of file descriptors. You can find out how many file descriptors you have with the limit command in csh.

You can increase file descriptors if you have enough privileges with the ulimit command in the csh. Otherwise, ask your system administrator to increase the file descriptors available to your processes.

a. EJBException is thrown

b. ObjectNotFoundException is thrown

c. NoSuchEntityException is thrown

d. An empty enumeration is returned

Choice D is correct. Find methods that return a single remote reference throw a FinderException if an application error occurs and a ObjectNotFoundException if a matching bean cannot be found. The ObjectNotFoundException is a subtype of FinderException and is only thrown by find methods, which return single remote references.

The findByPrimaryKey() method returns only one remote reference since there is a one-to-one relationship between a primary key's value and an entity. Find methods that return an Enumeration or Collection type return an empty collection or enumeration if no matching beans can be found or throw a FinderException if an application error occurs. NoSuchEntityException is a system exception thrown by the ejbLoad() method of an entity bean when the database row to be loaded is not found and also by the ejbStore() method when the database row to be updated cannot be found. It is a subclass of EJBException.