Top 49 Bea Weblogic Server Interview Questions You Must Prepare 24.May.2024

Follow these steps:

  1. Generate XML from the DOM document tree.
  2. Serialize the generated DOM document to a StringWriter.
  3. Call toString on the StringWriter and pass it into message.setText.
  4. Publish the message.

This is an Oracle issue. According to Oracle's documentation, dynamic cursors can remain open from run to run in a session and are not closeable when a procedure closes. To work around this issue, you can increase the number of open cursors allowed in the database or you can reset the connection pool (close and reopen database connections in the connection pool).

To reset the connection pool, you can untarget and retarget the connection pool using the Administration Console. You can also use the reset() method through the JMX API or the RESET_POOL command on the WebLogic Server command line interface.

Here is what we use that works:

CallableStatement cstmt = conn.prepareCall("Begin procName;

where procName is the name of an Oracle stored procedure. This is standard Oracle SQL syntax that works with any Oracle DBMS.

You might also use the following syntax:

CallableStatement cstmt = conn.prepareCall("{call procName};");

This code, which conforms to the Java Extended SQL spec, will work with any DBMS, not just Oracle.

The NO_ACKNOWLEDGE acknowledge mode indicates that received messages do not need to be specifically acknowledged which improves performance, but risks that messages are lost. This mode is supported for applications that do not require the quality of service provided by session acknowledge and that do not want to incur the associated overhead. v Messages sent to a NO_ACKNOWLEDGE session are immediately deleted from the server. Messages received in this mode are not recovered and, as a result, messages may be lost and/or duplicate message may be delivered if an initial attempt to deliver a message fails.

Note: You should avoid using this mode if your application cannot handle lost or duplicate messages. Duplicate messages may be sent if an initial attempt to deliver a message fails.

In addition, we do not recommend that this acknowledge mode be used with persistent messaging, as it implies a quality of service that may be too low for persistent messaging to be useful.

The byte and message maximum values are quotas - not flow control. Message quotas prevent a WebLogic JMS server from filling up with messages and possibly running out of memory, causing unexpected results. When you reach your quota, JMS prevents further sends with a ResourceAllocationException (rather than blocking). You can set quotas on individual destinations or on a server as a whole.

The thresholds are also not flow control - though they would be better suited to that application than the quotas. The thresholds are simply settings that when exceeded cause a message to be logged to the console to let you know that you are falling behind.

Note that the messages maximum setting on a connection factory is not a quota. This specifies the maximum numbers of outstanding messages that can exist after they have been pushed from the server but before an asynchronous consumer has seen them; it defaults to a value of 10.

WebLogic JMS implements an optional JMS facility for defining a server-managed pool of server sessions. This facility enables an application to process messages concurrently. A ConnectionConsumer object uses a server session to process received messages. If message traffic is heavy, the connection consumer can load each server session with multiple messages to minimize thread context switching. Multiple connection consumers can share server sessions in a server session pool.

Your JDBC code may throw the following exception:

"The coordinator has rolled back the traction.
No further JDBC access is allowed within this traction."

The WebLogic JTS JDBC driver throws this exception when the current JDBC connection traction rolls back prior to or during the JDBC call. This exception indicates that the traction in which the JDBC connection was participating was rolled back at some point prior to or during the JDBC call.

The rollback may have happened in an earlier EJB invoke that was part of the traction, or the rollback may have occurred because the traction timed out. In either case, the traction will be rolled back, the connection returned to the pool and the database resources released. In order to proceed, the JTS JDBC connection must be closed and reopened in a new traction.

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.

WebLogic jDriver for Oracle always returns a Java object that preserves the precision of the data retrieved.

WebLogic jDriver for Oracle returns the following from the getObject() method:

  • For columns of types NUMBER(n) and NUMBER(m,n): a Double is returned if the defined precision of the column can be represented by a Double; otherwise BigDecimal is returned.
  • For columns of type NUMBER: Because there is no explicit precision, the Java type to return is determined based on the actual value in each row, and this may vary from row to row. An Integer is returned if the value has a zero-valued fractional component and the value can be represented by an integer.

For example, 1.0000 will be an integer. A long is returned for a value such as 123456789123.000@If a value has a non-zero fractional component, a Double is returned if the precision of the value can be represented by a Double; otherwise a BigDecimal is returned.

The Java Servlet API Specification v2.2 allows you to declaratively restrict access to specific Servlets and JSPs using the Web Application Deployment descriptor. Section 13.3.2 of the specification has an example deployment descriptor that uses declarative security.

As per the JMS specification, when you are in a traction, the acknowledgeMode is ignored. If acknowledge() is called within a traction, it is ignored.

The default length of a string bound to an OUTPUT parameter of a CallableStatement is 128 characters. If the value you assign to the bound parameter exceeds that length, you will get this error.

You can adjust the length of the value of the bound parameter by passing an explicit length with the scale argument to the CallableStatement.registerOutputParameter() method.

WebLogic JMS supports cluster-wide, trparent access to destinations from any server in the cluster. A system administrator can establish cluster-wide, trparent 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. 

Yes, as long as the communication is between source and target WebLogic domains that are both running release 6.1 SP3 or later, and the bridge is configured to use the Exactly-once quality of service.

Ways to get a thread dump:

  • Try running this from the command line (after running the setEnv script in /bea/wlserver6.1/config/mydomain/):

java weblogic.Admin -url t3://localhost:7001 THREAD_DUMP

  • On Windows, from the console window, enter Ctrl+Break.
  • On UNIX, signal the server using kill -@

When you are testing your Oracle database connections under UNIX, you can run SQL*PLUS and can successfully ping the database using utils.dbping. However, when you use the multitier utils.t3dbping utility, you receive an ORA-12154 error message.

First, make sure that your ORACLE_HOME environment variable is correctly set to point to your Oracle installation. This variable must be set in the environment where the WebLogic server is running.

In the C-shell issue the following command:

$ setenv ORACLE_HOME path

where path is the path to your Oracle installation.

In the Bourne shell, issue the following commands:

$ export ORACLE_HOME

where path is the path to your Oracle installation. When you ping your database using the two-tier utils.dbping utility, the JDBC driver loads the database client library and establishes the connection to the database. When you use the multitier utils.t3dbping utility, the WebLogic Server loads a two-tier driver and uses it to establish a database connection. In both cases, the same method is used to connect to the database. SQL*PLUS works because it doesn't require ORACLE_HOME to find the client libraries.

If you are still experiencing problems, try this:

  • Open a command shell.
  • Run the two-tier version of utils.dbping in this shell.
  • Start WebLogic in this shell from the command line:
    $ java -ms32m -mx32m weblogic.server
  • Open a second command shell.
  • Run the utils.t3dbping in the second shell against the server running in the first command shell.

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.

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 trport. 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 JavaBe (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.

You can install VisualCafe Enterprise Edition 4.1 and attach it to the server, pretty much as it worked for 3.X.

The following are steps for debugging using VC 4.@You may change the directory names as necessary:

  • Install it under D:VisualCafeEE. No special options are needed.
  • Install the license under C:Program FilesCommon FilesWebGain Shared.
  • Start ddservices by selecting Start -> Programs -> WebGain Studio Professional ->Visual Cafe Enterprise Edition 4.1 -> Distributed Debugging Services -> Start DD Services (Java2 - 1.3)
  • Start WebLogic Server using debugvm.exe instead of java.exe.

cd D:beawlserver6.1configmydomain
edit startWebLogic.cmd
change "%JAVA_HOME%binjava" -hotspot -ms64m -mx64m to visualcafeEEjdk13bindebugvm.exe

  • Run startWebLogic. It prints out some debugging information.
  • Run VisualCafe - Start -> Programs -> WebGain Studio Professional -> Visual Cafe Enterprise Edition 4.1 -> Visual Cafe Enterprise Edition 4.1
  • From the File menu, select Attach to Process. If everything is working correctly, you should see your machine name.
  • Click the + sign to expand the tree and select your running WebLogic Server.

The way concurrency is achieved for Queues is by spawning one JMSSession per MDB instance in the pool. Since JMSSessions are processed in parallel by JMS, concurrency is obtained naturally this way and JMS takes care of delivering the message to, at most, one listener. If an MDB is deployed to multiple servers in a cluster, JMSSessions are created for each MDB instance on each server and load balancing will be done across them.

For Topics in WebLogic JMS 6.1, there is one JMSSession per bean instance in the pool. Because of the way Topics work, the session, and thus every bean instance, receives a copy of each message published on that Topic. (There was also a problem that caused parallel processing not to work correctly. This has been fixed for WLS 6.0 Service Pack 1.)

Within a single server, one topic consumer is used to pass out messages to multiple threads to get the concurrency while producing only a single copy of each message. You can configure multiple MDBs to listen on the same topic and each MDB will receive a copy of every message. When using multiple servers, each server gets its own consumer and therefore its own copy of each message. It is not currently possible to share a consumer across multiple servers. If you want a message to be processed by exactly one MDB, use a queue.

One customer had an example where topic MDBs are needed in which there will be multiple implementations of the MDBs listening on the same topic. In other words, more than one MDB with a different implementation may be subscribing to the same topic. The client has no advanced way of knowing how many different kinds of MDBs may be listening on the same topic, but it is possible for there to be more than one listener, therefore topics, not queues. For each kind of MDB listening on the topic, the message is delivered exactly once (i.e., the message will be delivered exactly once to an instance in each named MDB pool listening on the topic).

You can use a shutdown class that does something like the following:
JMSobject WLSobject = null;
WLSobject = JMSStartUp.getJMSobject();
catch(Exception e)
Servlets can provide a nice solution to provide both initialization and cleanup.

Each instance of MS SQL Server must be listening on a different port. So, you can use the port number in the properties that you pass to the getConnection() method or, in case of connection pools,

you can specify the port property in the following properties:

  • server=machineName
  • port=instancePort

To find the port number where each MS SQL Server instance is running, run the server network utility (in the Microsoft SQL Server program group), select the server instance, select TCP/IP, and click the properties button.

Quotas can be used to help this situation. Your sender will then receive ResourceAllocationExceptions and the server will stay up. WLS 6.X does not support paging of messages out of memory.

As of WLS 6.1 SP02 or later, you can use the Message Paging feature, which can free up valuable virtual memory during peak message load periods by swapping out messages from virtual memory to persistent storage when message loads reach a specified threshold.

No, there's no way to allow a request to wait for a pool connection, and from the system point of view there should not be. Each requests that waits for a connection ties up one of the fixed number of execute threads in the server, which could otherwise be running another server task. Too many waiting requests could tie up all of the execute threads and freeze the server.

Pending me the message could have been:

  • sent in a traction but not committed.
  • received and not acknowledged.
  • received and not committed.
  • subject to a redelivery delay (as of WebLogic Server 6.1).
  • subject to a delivery time (as of WebLogic Server 6.1).

A rolled back message remains pending until the traction actually rolls back. Rolling it back multiple times does not cause double counting, nor does an exception that set a traction as rollbackOnly followed by an actual rollback.

Current implies messages that are not pending.

Total implies total since server last started. The byte counts only consider the payload of messages which includes the properties and the body but not the header.

No, this is not supported:

  • Write your own interfaces using JNI.
  • Setup a Servlet that your C/C++ client calls to generate a JMS message. You should spawn multiple threads in C++ and use multiple posts to pass messages via http.

Yes. You have no JMS context inside the MDB so you will need to establish a connection, session and producer yourself. One option is to do this every time you come into the onMessage routine for the MDB. This is sufficient if the message rate is relatively low. The second option is to establish the necessary objects in ejbActivate().

Note that the objects are not serializable so they can't be passivated for a stateful session bean or an entity bean. When the EJB deactivates, you need to close the associated objects. The third option is that you could build up a JMS connection/sender session pool within a startup class complete with your own synchronization and blocking to get a connection.

The JMS database can be any database that is accessible through a JDBC driver.

WebLogic supports and provides JDBC drivers for the following databases:

  • Cloudscape
  • Informix
  • Microsoft SQL (MSSQL) Server (Versions 6.5 and 7)
  • Oracle (Version 8.1.6)
  • Sybase (Version 12)

No. Within an unsigned applet, you cannot load native libraries over the wire, access the local file system, or connect to any host except the host from which you loaded the applet. The applet security manager enforces these restrictions on applets as protection against applets being able to do unsavory things to unsuspecting users.

If you are trying to use jDriver for Oracle from an applet, then you are violating the first restriction. Your applet will fail when it attempts to load the native (non-Java layer) library that allows jDriver for Oracle to make calls into the non-Java Oracle client libraries. If you look at the exception that is generated, you will see that your applet fails in java.lang.System.loadLibrary, because the security manager determined that you were attempting to load a local library and halted the applet.

You can, however, use the WebLogic JTS or Pool driver for JDBC connectivity in applets. When you use one of these WebLogic multitier JDBC drivers, you need one copy of WebLogic jDriver for Oracle (or any other two-tier JDBC driver) for the connection between the WebLogic Server and the DBMS.

This error occurs when you have not set the ORACLE_HOME environment variable properly - a common mistake. In order to use WebLogic jDriver for Oracle, the Oracle client software needs to be installed and ORACLE_HOME must be set.

You may also see this error message if you try to use WebLogic jDriver for Oracle's internationalization capabilities with a language/codeset combination that is not installed on your system. If you get the ORA-12705 error with the correct error text, then either you have set NLS_LANG improperly, or you do not have the right codesets installed on your system.

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.

The fundamental problem is too few resources (database connections in the connection pool) for the work load. The correct response is to increase the maximum number of connections in the connection pool. Optimally designed applications only require the server to have one pool connection per execute thread.

The proper application response to a resource exception is not to retry the request in a tight loop, which would tie up execute threads on the server.

You should design your application to gracefully fail if no connections are available. Try to ensure that you get the connection as late as possible in your application code and return them to the pool as early as possible so that you do not see as many NoResource exceptions. It is better to have the connection as a method level variable and close the connection in a finally block as in the following example:

} catch(Exception handleEx) {
} finally {
try{ conn.close();
}catch (Exception ignore){} // always return the connection to pool

Using N sessions for N subscribers gives you concurrency up to N simultaneous threads of execution provided you have as many threads to work with. Each Session gets its own thread as long as there are enough threads available. Otherwise, the sessions serially reuse the available threads.

One session for N subscribers serializes all subscribers through that one session. If the load is heavy they may not be able to keep up without the extra threads.

If you are using CLIENT_ACKNOWLEDGE, N sessions gives you N separate message streams that can be individually recovered. Having one session crosses the streams giving you less control.

You must create a template on every JMSServer where you want to be able to create temporary destinations. You can specify multiple JMSServer entries to support Temporary Template and the system will load balance among those JMS servers to setup the temporary destination.

The JMSServer is defined something like:

 After the template name, you can set any queue/topic attribute you want in the template (not including a JNDI name or topic multicast settings). The template is at the outer most level; that is, it should not be nested in your .

Temporary destinations can only be consumed by the creating connection. Using topics, you create your temporary topic and subscribe to that temporary topic. If you want someone to publish to that temporary topic, you need to tell that someone what your topic is. You can send them a message and include your temporary topic in the JMSReplyTo field. The creator of the TemporaryTopic and the subscriber must be one in the same.

import javax.jms.TopicSession;
TemporaryTopic myTopic = mySession.createTemporaryTopic();
TopicSubscriber = mySession.createSubscriber(myTopic);

Temporary topics do not get names and cannot be subscribed to by other connections. When you create a temporary topic, the JMS provider returns a javax.jms.Topic. You then need to advertise that topic to other parties (those who want to publish to the topic), putting it in your JMSReplyTo field so that they can respond. In general, no one else can subscribe to the topic. You advertise the topic any way you want. Topics are serializable (or, in our case, externalizable), which allows you to pass them around in RMI calls, through a file, binding it to a name in JNDI, etc. In short, create the topic at the subscriber side and advertise so that others can publish. You can get multiple subscribers on the same connection and get concurrent processing using multiple sessions.

"CORBA" support me many things to many people. It often me 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 JavaBe.

We bundle a parser, based on Apache's Xerces 1.3.1 parser, in WebLogic Server 6.@In addition, we include a WebLogic proprietary high-performance non-validating parser that you can use for small to medium sized XML documents. The WebLogic XML Registry allows you to configure the parser you want to use for specific document types.

The following are several approaches:

  • Use a tracted session, then rollback the session so the message will go back to the queue.
  • Use Session.CLIENT_ACKNOWLEDGE when creating a session, then recover the session so the message will go back to the queue.
  • Use a JTA traction, then rollback the traction so the message will go back to the queue.

Yes, as long as the WebLogic 7.0 domain is using Service Pack 1 or later. To enable durable messages across the messaging bridge using the Administration Console, select the Durability Enabled attribute on the Messaging Bridge -> Configuration -> General tab.

The EJB Specification prohibits this behavior, and the weblogic.ejbc compiler checks for this behavior and prohibits any polymorphic type of response from a create() or find() method.

The reason the create() and find() methods are not polymorphic is similar to the reason constructors are not polymorphic in Java. The derived classes generally do not know or cannot initialize the base class properly.

Yes, just make sure to select the QOS Degradation Allowed check box on the Messaging Bridge -> Configuration -> General administration console page.

Threads should generally not be created by the user directly is because things may not work correctly. User-created threads do not have some of the thread-local variables pre-set by WebLogic when it creates it's own execute threads, the associated traction context, or the environment such as the proper class loader.

The WebLogic-specific way of doing this is with a startup class or using the WebLogic Time Services. The portable way to do this is to define a load-on-startup servlet, doing the initialization in the init() method and the cleanup in the destroy() method.

The servlet itself does nothing. This approach also allows for undeploy/redeploy of the application without restarting the server, including proper cleanup/initialization each time. It also providers more dynamic management of the dependent classes without restarting the server.

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.

The exception is usually something like or java.lang.NoClassDefFoundError.

Make sure weblogic.jar is in the CLASSPATH of the client. Also make sure you have the correct Java run-time jar files included (i.e., you might need rt.jar).

Suppose you are trying to tget the PreparedStatement class to bind Strings in a statement. The setString() method doesn't seem to work.

Here is how you have set up the PreparedStatement:

String pstmt = "select n_name from n_table where n_name LIKE
PreparedStatement ps = conn.prepareStatement(pstmt);
ps.setString(1, "SMIT");
ResultSet rs = ps.executeQuery();

The preceding code does not work because the complete value needs to be specified in a String (without using embedded quotes) and then bound to an unquoted question-mark (?).

Here is the corrected code:

String matchvalue = "smit%";
String pstmt = "select n_name from n_table where n_name LIKE ?";
PreparedStatement ps = conn.prepareStatement(pstmt);
ps.setString(1, matchvalue);
ResultSet rs = ps.executeQuery();

Clients that connect to a WebLogic Server cluster and look up a clustered object obtain a replica-aware stub for the object. This stub contains the list of available server instances that host implementations of the object. The stub also contains the load balancing logic for distributing the load among its host servers.

The correct way to set up security for JMS is to go to the console, select ACLs in the tree view, then create some access control lists.

  • Set the ACL name which should be weblogic.jms.queue.QUEUENAME or weblogic.jms.topic.TOPICNAME.
  • elect Create.
  • Enter the New Permission of send or receive.
  • Select Create.
  • Enter a comma separated list of users or groups.
  • Select Grant Permission.
  • Select "saved to the realm implementation" to save your changes.
  • Select Yes.

This will update the file with lines that look like the following:


If you don't have an ACL for a queue or topic, security is wide open.There are also ACL's for accessing the JNDI context; the JNDI context is a requirement for initially accessing JMS. 

Yes. Beginning with WebLogic Server version 6.0, EJBs must be homogeneously deployed across a cluster for the following reasons:

  • To keep clustering EJBs simple
  • To avoid cross server calls which results in more efficiency. If EJBs are not deployed on all servers, cross server calls are much more likely.
  • To ensure that every EJB is available locally
  • To ensure that all classes are loaded in an undeployable way
  • Every server must have access to each EJB's classes so that it can be bound into the local JNDI tree. If only a subset of the servers deploys the bean, the other servers will have to load the bean's classes in their respective system classpaths which makes it impossible to undeploy the be.

BEA WebLogic is a J2EE application server and also an HTTP web server by BEA Systems of San Jose, California, for Unix, Linux, Microsoft Windows, and other platforms. WebLogic supports Oracle, DB2, Microsoft SQL Server, and other JDBC-compliant databases. WebLogic Server supports WS-Security and is compliant with J2EE 1.3.

BEA WebLogic Server is part of the BEA WebLogic Platform. The other parts of WebLogic Platform are:

  • Portal, which includes Commerce Server and Personalization Server (which is built on a BEA-produced Rete rules engine),
  • WebLogic Integration,
  • WebLogic Workshop, an IDE for Java, and
  • JRockit, a JVM for Intel CPUs.

WebLogic Server includes .NET interoperability and supports the following native integration capabilities:

  • Native enterprise-grade JMS messaging
  • J2EE Connector Architecture
  • WebLogic/Tuxedo Connector
  • COM+ Connectivity
  • CORBA connectivity
  • IBM WebSphere MQ connectivity

BEA WebLogic Server Process Edition also includes Business Process Management and Data Mapping functionality. WebLogic supports security policies managed by Security Administrators.

The BEA WebLogic Server Security Model includes:

  • Separate application business logic from security code
  • Complete scope of security coverage for all J2EE and non-J2EE components

Due to the fact that the current configuration and packaging requirements for resource adapters in WebLogic Server require the hand-editing of the weblogic-ra.xml file, any new passwords specified in the security-principal-map entries are done in clear-text.

BEA understands the importance of protecting security passwords. Hence, we provide a Converter Tool that allows for the encryption of all passwords present in the weblogic-ra.xml file. The Converter Tool is shipped in the standard weblogic.jar file.