How are notifications made when a server is added to a cluster?

The WebLogic Server cluster broadcasts the availability of a new server instance each time a new instance joins the cluster. Cluster-aware stubs also periodically update their list of available server instances.

How does a server know when another server is unavailable?

WebLogic Server uses two mechanisms to determine if a given server instance is unavailable.

Each WebLogic Server instance in a cluster uses multicast to broadcast regular "heartbeat" messages that advertise its availability. By monitoring heartbeat messages, server instances in a cluster determine when a server instance has failed. The other server instances will drop a server instance from the cluster, if they do not receive three consecutive heartbeats from that server instance

WebLogic Server also monitors socket errors to determine the availability of a server instance. For example, if server instance A has an open socket to server instance B, and the socket unexpectedly closes, server A assumes that server B is offline.

How do you set the classpath?

WebLogic Server installs the following script that you can use to set the classpath that a server requires:

WL_HOME\server\bin\setWLSEnv.cmd (on Windows)

WL_HOME/server/bin/setWLSEnv.sh (on UNIX)

What is the function of T3 in WebLogic Server?

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, or an ORB and WebLogic Server-IIOP.

Can I start a Managed Server if the Administration Server is unavailable?

By default, if a Managed Server is unable to connect to the specified Administration Server during startup, it can retrieve its configuration by reading a configuration file and other files directly. You cannot change the server's configuration until the Administration Server is available. A Managed Server that starts in this way is running in Managed Server Independence mode.

How do I provide user credentials for starting a server?

When you create a domain, the Configuration Wizard prompts you to provide the username and password for an initial administrative user. If you create the domain in development mode, the wizard saves the username and encrypted password in a boot identity file. A WebLogic Server instance can refer to a boot identity file during its startup process. If a server instance does not find such a file, it prompts you to enter credentials.

If you create a domain in production mode, or if you want to change user credentials in an existing boot identity file, you can create a new boot identity file.

Domain Directory Contents

By default, WebLogic Server creates domain directories under the BEA_HOME/user_projects/domains directory

domain-name

The name of this directory is the name of the domain.

autodeploy

This directory provides a quick way to deploy applications in a development server. When the WebLogic Server instance is running in development mode, it automatically deploys any applications or modules that you place in this directory.

The files you place in this directory can be Java EE applications, such as:

• An EAR file
• A WAR, EJB JAR, RAR, or CAR archived module
• An exploded archive directory for either an application or a module

bin

This directory contains scripts that are used in the process of starting and stopping the Administration Server and the Managed Servers in the domain. These scripts are generally provided as .sh files for UNIX and .cmd files for Windows. The bin directory can optionally contain other scripts of domain-wide interest, such as scripts to start and stop database management systems, full-text search engine processes, etc. 

config

This directory contains the current configuration and deployment state of the domain. The central domain configuration file, config.xml, resides in this directory.

config/configCache

Contains data that is used to optimize performance when validating changes in the domain’s configuration documents. This data is internal to WebLogic Server and does not need to be backed up.

config/diagnostics

This directory contains system modules for instrumentation in the WebLogic Diagnostic Framework. 

config/jdbc

This directory contains system modules for JDBC: global JDBC modules that can be configured directly from JMX (as opposed to JSR-88). 

config/jms

This directory contains system modules for JMS: global JMS modules that can be configured directly from JMX (as opposed to JSR-88). 

config/lib

This directory is not used in the current release of WebLogic Server.

config/nodemanager

This directory holds configuration information for connection to the Node Manager. 

config/security

This directory contains system modules for the security framework. It contains one security provider configuration extension for each kind of security provider in the domain’s current realm. 

config/startup

This directory contains system modules that contain startup plans. Startup plans are used to generate shell scripts that can be used as part of server startup.

configArchive

This directory contains a set of JAR files that save the domain’s configuration state. Just before pending changes to the configuration are activated, the domain’s existing configuration state, consisting of the config.xml file and the other related configuration files, is saved in a versioned JAR file with a name like config.jar#1, config.jar#2, etc.

The maximum number of versioned JAR files to be kept is specified by the archiveConfigurationCount attribute of DomainMBean. Once this maximum number is reached, the oldest conversion archive is deleted before a new one is created.

console-ext

This directory contains extensions to the Administration Console, which enable you to add content to the WebLogic Server Administration Console, replace content, and change the logos, styles and colors without modifying the files that are installed with WebLogic Server. For example, you can add content that provides custom monitoring and management facilities for your applications. 

init-info

This directory contains files used for WebLogic domain provisioning. You should not modify any files in this directory.

lib

Any JAR files you put in this directory are added to the system classpath of each server instance in the domain when the server’s Java virtual machine starts.

pending

This directory contains domain configuration files representing configuration changes that have been requested, but not yet activated. Once the configuration changes have been activated, the configuration files are deleted from this directory. 

This directory holds those security-related files that are the same for every WebLogic Server instance in the domain:

• SerializedSystemIni.dat

This directory also holds security-related files that are only needed by the domain’s Administration Server:

• DefaultAuthorizerInit.ldift
• DefaultAuthenticatorInit.ldift
• DefaultRoleMapperInit.ldift

servers

This directory contains one subdirectory for each WebLogic Server instance in the domain. The subdirectories contain data that is specific to each server instance.

servers/server-name

This directory is the server directory for the WebLogic Server instance with the same name as the directory.

servers/server-name/bin

This directory holds executable or shell files that can be or must be different for each server. The server environment script (setServerEnv.sh or setServerEnv.cmd) is an example of a file that resides here because it can differ from one WebLogic Server instance to the next, for example, depending on whether the server instance has its own startup plan.

servers/server-name/cache

This directory holds directories and files that contain cached data. By “cached” here we mean that the data is a copy, possibly in a processed form (compiled, translated, or reformatted), of other data.

servers/server-name/cache/EJBCompilerCache

This directory is a cache for compiled EJBs.

servers/server-name/data

This directory holds files that maintain persistent per-server state used to run the WebLogic Server instance, other than security state, as opposed to temporary, cached or historical information. Files in this directory are important data that must be retained as the WebLogic Server instance is brought up, is brought down, crashes, restarts, or is upgraded to a new version.

servers/server-name/data/ldap

This directory holds the embedded LDAP database. The runtime security state for the WebLogic Server instance is persisted in this directory.

servers/server-name/data/store

This directory holds WebLogic persistent stores. For each persistent store, there is a subdirectory that holds the files that represent the persistent store. The name of the subdirectory is the name of the persistent store. By convention there is one store named default.

servers/server-name/logs

This directory holds logs and diagnostic information. This information is historical in nature. It is not crucial to the operation of the server, and can be deleted (while the WebLogic Server instance is down, at least) without affecting proper operation. However, the information can be quite useful for debugging or auditing purposes and should not be deleted without good reason.

servers/server-name/logs/diagnostic_images

This directory holds information created by the Server Image Capture component of the WebLogic Diagnostic Framework. 

servers/server-name/logs/jmsServers

This directory contains one subdirectory for each JMS server in the WebLogic Server instance. Each such subdirectory contains the logs for that JMS server. The name of the subdirectory is the name of the JMS server.

servers/server-name/logs/connector

This directory is the default base directory for connector module (JCA ResourceAdapter) logs.

servers/server-name/security

This directory holds security-related files that can be or must be different for each WebLogic Server instance. The file boot.properties is an example of a file that resides here because it can differ from one server to the next. This directory also maintains files related to SSL keys.

servers/server-name/tmp

This directory holds temporary directories and files that are created while a server instance is running. For example, a JMS paging directory is automatically created here unless another location is specified. Files in this directory must be left alone while the server is running, but may be freely deleted when the server instance is shut down.

tmp

This directory stores temporary files used in the change management process. You should not modify any files in this directory.

user_staged_config

By default, configuration information is automatically copied from the Administration Server to each Managed Server. If instead you prefer to stage configuration changes manually, you can use this directory as an alternative to the config directory.

Deployment : Creating War file and directory structure

WAR Directory Structure
    

Develop your Web Application within a specified directory structure so that it can be archived and deployed on WebLogic Server or another J2EE-compliant server. All servlets, classes, static files, and other resources belonging to a Web Application are organized under a directory hierarchy. The root directory of this hierarchy defines the document root of your Web Application. All files under this root directory can be served to the client, except for files under the special directory WEB-INF, located under the root directory.
********************************************************************************************************

Place private files in the WEB-INF directory, under the root directory. All files under WEB-INF are private, and are not served to a client.

DefaultWebApp/

Place your static files, such as HTML files and JSP files in the directory that is the document root of your Web Application. In the default installation of WebLogic Server, this directory is calledDefaultWebApp, under user_domains/mydomain/applications.

DefaultWebApp/WEB-INF/web.xml

The Web Application deployment descriptor that configures the Web Application.

DefaultWebApp/WEB-INF/weblogic.xml

The WebLogic-specific deployment descriptor file that defines how named resources in the web.xml file are mapped to resources residing elsewhere in WebLogic Server. This file is also used to define JSP and HTTP session attributes.

DefaultWebApp/WEB-INF/classes

Contains server-side classes such as HTTP servlets and utility classes.

DefaultWebApp/WEB-INF/lib

Contains JAR files used by the Web Application, including JSP tag libraries.

**********************************************************************************

Creating Web Applications: Main Steps

Here are the main steps for creating a Web application:

1. Create the HTML pages and JavaServer Pages (JSPs) that make up the Web interface of the Web application. Typically, Web designers create these parts of a Web application.
   
   
2. Write the Java code for the servlets and the JSP taglibs referenced in JSPs. Typically, Java programmers create these parts of a Web application.
3. Compile the servlets into class files.
4. Arrange the resources (servlets, JSPs, static files, and deployment descriptors) in the prescribed directory format. ( as above in red )
5. Create the web.xml and weblogic.xml deployment descriptors.
   The web.xml file defines each servlet and JSP page and enumerates enterprise beans referenced in the Web application. The weblogic.xml file adds additional deployment information for WebLogic Server.
   Create the web.xml and weblogic.xml deployment descriptors manually or using WebLogic Builder. 
   
   
6. Package the HTML pages, servlet class files, JSP files, web.xml file, and weblogic.xml file into a WAR file.
   Create a Web application staging directory and save the JSPs, HTML pages, and multimedia files referenced by the pages in the top level of the staging directory.
   Store compiled servlet classes, taglibs, and, if desired, servlets compiled from JSP pages are stored under a WEB-INF directory in the staging directory. When the Web application components are all in place in the staging directory, you create the WAR file with the JAR command.
7. Auto-deploy the WAR file on WebLogic Server for testing purposes.
   While you are testing the Web application, you might need to edit the Web application deployment descriptors. You can do this manually or use WebLogic Builder.
8. Deploy the WAR file on the WebLogic Server for production use or include it in an Enterprise ARchive (EAR) file to be deployed as part of an enterprise application.

Application Deployment as a Library

J2EE library support in WebLogic Server 9.x onwards provides an easy way to share one or more J2EE modules or JAR files among multiple Enterprise Applications. 


A J2EE library is a stand-alone J2EE module, multiple J2EE modules packaged in an Enterprise Application (EAR), or a plain JAR file that is registered with the J2EE application container upon deployment. 


After a J2EE library has been registered, you can deploy Enterprise Applications that reference the library. 


Each referencing application receives a copy of the shared J2EE library module(s) on deployment, and can use those modules as if they were packaged as part of the application itself.


you need to select "Install this application as a Library" during deployment then target it to the servers where deployed applications need to access these library files.

Quick Deployment using WLST

You can use WLST to quickly deploy an Application  File in a Weblogic Server.

What do you need ?

• The ear/war/rar/jar  file ( uploaded to a directory in the target WebLogic Server )
• A simple WLST script
• Credentials for the Weblogic Server ( preferrably, the weblogic user ).

• Write a simple WLST Script to do your work and save it as "deploy.py"

print '*** WEBLOGIC : START ***'

print 'connecting to admin server....'

connect( 'weblogic', 'webl0gic', 't3://localhost:7001', adminServerName='AdminServer' )

print 'stopping and undeploying ....'

stopApplication('shoppingcart')

print 'deploying....'

deploy('shoppingcart', 'c:/shoppingcart.war', targets='AdminServer')

startApplication('shoppingcart')

print 'disconnecting from admin server....'

disconnect()

exit()

print '*** WEBLOGIC : STOP ***'

• Open a Terminal Window / Command Prompt
• Run the setDomainEnv.sh ( or setDomainEnv.bat ) script to set the required environment variables under <domain>/bin.
• run :-  java weblogic.WLST deploy.py

output -

*************************************************************************************************************

java weblogic.WLST sc

ript.py

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

*** WEBLOGIC : START ***

connecting to admin server....

Connecting to t3://localhost:7001 with userid weblogic ...

Successfully connected to Admin Server 'AdminServer' that belongs to domain 'bas

e_domain'.

Warning: An insecure protocol was used to connect to the

server. To ensure on-the-wire security, the SSL port or

Admin port should be used instead.

stopping and undeploying ....

Stopping application shoppingcart.

<Oct 20, 2010 2:10:43 PM IST> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiat

ing stop operation for application, shoppingcart [archive: null], to AdminServer

 .>

Completed the stop of Application with status completed

Current Status of your Deployment:

Deployment command type: stop

Deployment State       : completed

Deployment Message     : no message

deploying....

Deploying application from c:\shoppingcart.war to targets AdminServer (upload=fa

lse) ...

<Oct 20, 2010 2:10:44 PM IST> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiat

ing deploy operation for application, shoppingcart [archive: c:\shoppingcart.war

], to AdminServer .>

.Completed the deployment of Application with status completed

Current Status of your Deployment:

Deployment command type: deploy

Deployment State       : completed

Deployment Message     : no message

Starting application shoppingcart.

<Oct 20, 2010 2:10:48 PM IST> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiat

ing start operation for application, shoppingcart [archive: null], to AdminServe

r .>

.Completed the start of Application with status completed

Current Status of your Deployment:

Deployment command type: start

Deployment State       : completed

Deployment Message     : no message

disconnecting from admin server....

Disconnected from weblogic server: AdminServer

Exiting WebLogic Scripting Tool.

<Oct 20, 2010 2:10:51 PM IST> <Warning> <JNDI> <BEA-050001> <WLContext.close() w

as called in a different thread than the one in which it was created.>

************************************************************************************************************