Decrypt weblogic passwords:

Set environment by going to:
source $DOMAIN_HOME/bin/setDomainEnv.sh

Go to --> cd $DOMAIN_HOME/security  and create a file decrypt.py with below contents:

from weblogic.security.internal import *  
from weblogic.security.internal.encryption import *

encryptionService = SerializedSystemIni.getEncryptionService(".")  
clearOrEncryptService = ClearOrEncryptedService(encryptionService)

passwd = raw_input("Enter encrypted password of one which you wanted to decrypt : ")

plainpwd = passwd.replace("\\", "")

print "Plain Text password is: " + clearOrEncryptService.decrypt(plainpwd)  

Go to $DOMAIN_HOME/config/jdbc and get the encrypted password for any data source you need

Run the command java weblogic.WLST decrypt.py in cd $DOMAIN_HOME/security

Input your encrypted password while prompted. 

java weblogic.WLST plainpassword.py  
Initializing WebLogic Scripting Tool (WLST) ...  
Welcome to WebLogic Server Administration Scripting Shell  
Type help() for help on available commands  
Enter encrypted password of one which you wanted to decrypt : {AES}LsGaddassssvQDyibmejXFkf1tWxyndNArAhZ3M5GcnjXWUpJs=  
Plain Text password is: ######

Weblogic Basics

WebLogic Server Instance

             

                A WebLogic Server instance is a Java Virtual Machine (JVM) process that runs the Java code. The

instance is the actively working component, receiving client requests and sending them on to

the appropriate components, and sending the processed requests back to the clients.

Weblogic server instance is combination of admin server + manage server.

Administration Server

            A server is an instance of WebLogic Server that runs in its own JVM, and the Admin Server is a special instance of  WebLogic Server designed for managing the domain rather than running applications. There is a one-to-one relationship between domains and the Admin Server—an Admin Server belonging to Domain A can’t manage Domain B.

            You can deploy applications on the Admin Server, but unless you’re operating in a purely developmental environment, use the Admin Server strictly for performing management tasks, not for deploying any applications. Although you can deploy applications on the Admin Server in a development environment, it’s a best practice not to do so in a production environment

Managed Server

            Managed servers are the workhorses of WebLogic Server. Any additional servers you create after the creation of the default Admin Server are Managed Servers. The Managed Server contacts the Admin Server, only when you start it up, to get the configuration and deployment settings. For this reason, you should always start up the Admin Server before you start a Managed Server. Once a Managed Server starts running, it operates completely independent of the Admin Server.

WebLogic Server Cluster

            A WebLogic Server cluster is a group of WebLogic Server instances consisting of multiple Managed Servers that run simultaneously.

Machine

            A machine in the WebLogic Server context is the logical representation of the computer that hosts one or more WebLogic Server instances (servers).

Node Manager

            Node Managers help you remotely start, stop, suspend, and restart Managed Servers.

Services

            Following are some of the main services used in a WebLogic environment:

■ JDBC (Java Database Connectivity) enables Java programs to handle database

connections established through connection pools.

■JMS (Java Messaging Service) is a standard API that enables applications to communicate

through enterprise messaging systems.

■JTA (Java Transaction API) specifies standard Java interfaces between transaction

managers and the parties in a distributed transaction system.

Development and Production Mode

            By default, WebLogic Server domains run in the development mode using the Sun Java Development Kit (JDK). In this mode, auto-deployment of applications is enabled and the Admin Server creates a boot.properties file automatically when you start it up. You can also use the demo certificates for Secure Sockets Layer (SSL) without any warnings from WebLogic Server. The development mode is provided to get developers up and running quickly without having to worry

about advanced deployment, configuration, or security issues.

In the production mode, WebLogic Server defaults to using JRockit as the default JDK. In addition, you can’t use the auto-deployment feature in production, and WebLogic Server issues warnings if you use the demo certificates for SSL. In the production mode, you’re also prompted for usernames and password when you start up the instances.

It’s easy to toggle between the development and production modes

Understanding Data Sources and Connection Pool in Weblogic

Terms like datasources and connection pools are very familiar to weblogic developers and admins.

Most of the times developer ask for datasource creation on weblogic servers. Developers or admins who have worked on Oracle Application server also will be familiar with these terms. Newbies often get confused about these and the difference between the two.

In simple terms Applications deployed on weblogic servers(managed servers) use the datasources( created on Weblogic server level) to connect to the databases.

Though the connection can be made at the deployed code level(JDBC connect strings) Data sources and their connection pools provide connection management processes that help keep your system running and performant.You can set options in the data source to suit your applications and your environment.

I explain the concepts in more details below:



Data Sources

In WebLogic Server, you configure database connectivity by adding data sources to your WebLogic domain. WebLogic JDBC data sources provide database access and database connection management. Each data source contains a pool of database connections that are created when the data source is created and at server startup. Applications reserve a database connection from the data source by looking up the data source on the JNDI tree or in the local application context and
then calling getConnection(). When finished with the connection, the application should call connection.close() as early as possible, which returns the database connection to the pool for other applications to use.


Connection Pool

Each JDBC data source has a pool of JDBC connections that are created when the data source is deployed or at server startup. Applications use a connection from the pool then return it when
finished using the connection. Connection pooling enhances performance of the application server or deployed application response time by eliminating the costly task of creating database connections for the application.


Hope the above post helps. In future posts I would write on how to create connection pools in Weblogic and more importantly tuning them.