Administration of WebLogic
• Administration of WebLogic can be done using command line arguments.
- Admin is a java class that can be run, if you know how to use it.
- Admin is part of the WebLogic package and is contained in weblogic.jar. You can find in the lib folder
under <install directory>\wlserver6.0sp1.
- Since Admin is a Java class you will have to run java.
• The simplest admin function to call is PING. PING is used to verify that a server is running.
>set classpath=%classpath%;\lib\weblogic.jar
>java weblogic.Admin -url http://localhost:7001 PING 1 1
- This simple ping will show us that the server is running, by refusing the PING.
- To get the PING to successfully connect you will have to define a username and password for the
PING command.
- The following successfully pings our WLServer assuming your system password is “secret”.
>java weblogic.Admin -url "http://127.0.0.1:7001" –username system -password secret PING 1 10
- A successful result of a PING should look like the following.
Sending 1 ping of 10 bytes.
RTT = ~20 milliseconds, or ~20 milliseconds/packet
• Other Admin commands follow a very similar format.
- You will have to have weblogic.jar in your classpath.
- You will be running weblogic.Admin using java.exe for all of these commands.
- You will be using the same format for entering password and username for most of the commands.
- After you get PING working the hard part is really done, all of the commands are easy when you get
the format.
- If you want detail on commands you can run, either type in “java weblogic.Admin usage” to see the
usage, or visit http://www.weblogic.com/docs51/admindocs/weblogicserver.html.
• Although we will talk briefly about the other Admin commands available, we will not give detailed
examples of each. Follow the PING procedure and use “usage” to trouble shoot any difficulty.
- LOCK requires a system administrator password. Locking WLServer disables logins.
- UNLOCK is just the opposite of Lock.
- HELP will do similar work to usage.
- LIST will list a JNDI context for you. We talk about JNDI in more detail and see an easier way to see
the JNDI tree a bit later.
- SERVERLOG will list the contents of the server log.
- LICENSES will list your license information
WebLogic Console
• Much of the work you can do from the command line is easier to work with in the Console.
• To open the WebLogic console you use your browser.
- The WebLogic console is a HTTP/HTML application that makes configuring your WLS more
accessible.
- The command line administration tools are still essential. Administrators often create scripts to do
simple but repetitive work.
- To access the console you will open a browser and point it to your WLS domain with a /console after it.
- Assuming some defaults the URL for the console looks like this.
http://localhost:7001/console
• To access the console you need to know the system password. Following our example above it’s
“secret” in this demo.
• The console when you first open it should look like this.
• The console is a central point to work with the configuration of your WLServer.
- The configuration information is actually stored for each domain you create.
- The configuration information for your WLServer is basically the whole config folder. This folder is
found under <Install directory>\wlserver…
- The config folder contains one folder for each domain you create in the WLServer.
- The configuration information for each domain is contained in a config.xml file in the domain folder.
- When you successfully boot up the server the server will create a copy of the config.xml file called
config.xml.booted, if any changes you make in the console break your server you can uses config.xml.booted
to “roll back” the changes.
• The console is a fairly familiar layout for a visual application.
- The left side basically represents a navigation of features.
- The right side is information about what is selected on the left.
• The console is a nice visual representation that makes configuration files easier to work with, and
provides a GUI for admin tasks.
- Many of the changes you will invoke with the console will just be changes to an xml file called config.
xml
- Also the Admin commands issued can be done in the console without prior knowledge of the arguments
or classes involved.
• To demonstrate how to the console directly manipulates an xml file let’s add a startup class.
• A startup class is a Java class that is run at the end of the startup procedure.
- Startup classes typically will be responsible for setting up initial resources not taken care of by
anything else.
- Startup classes have a counter class type called the Shutdown class. You can probably imagine what a
shutdown class is.
• To configure our startup class we will go to the console and navigate to startup/shutdown. mydomain
> Deployments > Startup & Shutdown.
• Select “Create a new Startup Class” which will lead you to a screen where you can put in a few pieces
of information.
- The name is just any text name you want to call this particular startup, think of it as an alias. These
name/aliases appear for all configuration options, so get comfortable with it immediately.
- The Classname is the full name of the class you will create, remember to include in your package name.
To demo it we will create sclose.wls.SCStartup.
- The arguments you define here will be passed into your class inside of a Hashtable. A sample
arguments might be “source=sclose.jdb.util.FinalClass,destination=log.admin”
- Select or deselect the checkbox to have the WLS startup dependant on successfully running your
startup class.
• You must assign a target to your startup class, so select the “targets” tab and move your targeted
server, or cluster to the right hand “Chosen” list.
• Changes to the startup classes, unlike most changes will require a reboot to work.
• To shutdown the server navigate to your server, then move to the monitoring tab and find a link called
“Shutdown this Server …”.
- It might take a minute to shutdown the server.
- You can shutdown the server using the weblogic.Admin class if you prefer.
- You could also write a script to shutdown the server.
• The next step in our creation of a startup class is to code the class.
- A startup class should implement the weblogic.common.T3StartupDef interface.
- Instead of implementing the T3StartupDef interface, your class can define a typical main method. If
you don’t implement the interface, the server will use introspection and call the main method instead.
- Your server must find the startup class, so you must place the resulting bytecode (.class file) in the
classpath used by WLServer.
• Creating a class the implements weblogic.common.T3StartupDef is simple.
package sclose.wls;
import java.util.Hashtable;
import java.util.Enumeration;
import weblogic.common.T3StartupDef;
import weblogic.common.T3ServicesDef;
public class SCStartup implements T3StartupDef{
public String startup(String name, Hashtable ht)throws Exception{
System.out.println("The virtual name of this class is " + name);
Enumeration enum = ht.keys();
while(enum.hasMoreElements()){
String key = (String)enum.nextElement();
System.out.println("Arg Name: " + key + " Arg Value: " + ht.get(key));
}
System.out.println("END OF STARTUP METHOD");
return "Output from SCStartup Class";
}
public void setServices(T3ServicesDef def){
System.out.println("IN SETSERVICES");
}
}
• Your startup class, since it implements T3StartupDef will need to override two methods defined in
T3StartupDef.
- The setServices method will be called before startup is called.
- The startup method will be called to do any processing needed.
- To get this code to compile you need to include weblogic.jar in your class path so it can find
T3StartupDef and T3ServiceDef.
• Before restarting WLS you will need to modify the classpath, the simplest way to get this done is to
modify the startWebLogic.cmd file.
- Find the set CLASSPATH command in startWebLogic.
set CLASSPATH=.;.\lib\weblogic_sp.jar;.\lib\weblogic.jar
- Change the command to include the root directory of where you compiled your Startup class.
set CLASSPATH=.;.\lib\weblogic_sp.jar;.\lib\weblogic.jar;c:\Java_Root
• If configured correctly you should see output from your startup class being run by WLS.
INSETSERVICES
The virtual name of this class is stevesStartup
Arg Name: horton Arg Value: hears.a.who
END OF STARTUP METHOD
• This output reflects information from multiple locations.
- INSETSERVICES and END OF STARTUP METHOD are direct System.out.println’s found in the
Startup method.
- The output also includes “horton”, “hears.a.who” and “stevesStartup” which are strings we added in
the console.
- The string “Output from SCStartup Class” which is returned from the startup method did not appear in
this text.
- The string returned from startup will appear in the log file, and can appear in the console if you wish,
but it is a lower priority message and by default the server will filter out lower priority messages.
- You can reset what messages go to the command line in the console. Select myserver and the Logging
tab and look for “Stdout severity threshold”
- The output in the <install directory>\wlserver\logs\weblogic.log. The name and location of the log file
is configured on the same tab as the severity. It is commonly named weblogic.log or mydomain.log.
<Apr 19, 2001 3:59:32 PM CDT> <Info> <WebLogicServer> <sclose.wls.SCStartup repo
rts: Output from SCStartup Class>
• The console provides easy to understand access to the config.xml file.
• If you look in the config.xml file found in
<install directory>\wlserver\config\mydomain.
• Looking at config.xml we will find some very familiar information.
<Application Deployed="true" Name="console" Path=".\config\mydomain\applications">
<WebAppComponent Name="console" Targets="myserver" URI="console.war"/>
</Application>
<StartupClass Arguments="horton=hears.a.who"
ClassName="sclose.wls.SCStartup" FailureIsFatal="true"
Name="stevesStartup" Targets="myserver"/>
<Security GuestDisabled="false" Name="mydomain"
PasswordPolicy="wl_default_password_policy" Realm="wl_default_realm"/>
- Notice the “horton” and “hears.a.who”. I doubt that these strings were added by anyone else.
- This is a snippet of config.xml, the whole document is much larger than 9 lines.
- Config.xml is a standard xml file, and as such is fairly human readable.
• Instead of using the console you can make changes to config.xml directly if you prefer, and you are
comfortable with xml.
• For more details on config.xml and all the options you can choose look at http://e-docs.bea.
com/wls/docs60/config_xml/overview.html, which has links to more information about this configuration file.
• Administration of WebLogic can be done using command line arguments.
- Admin is a java class that can be run, if you know how to use it.
- Admin is part of the WebLogic package and is contained in weblogic.jar. You can find in the lib folder
under <install directory>\wlserver6.0sp1.
- Since Admin is a Java class you will have to run java.
• The simplest admin function to call is PING. PING is used to verify that a server is running.
>set classpath=%classpath%;\lib\weblogic.jar
>java weblogic.Admin -url http://localhost:7001 PING 1 1
- This simple ping will show us that the server is running, by refusing the PING.
- To get the PING to successfully connect you will have to define a username and password for the
PING command.
- The following successfully pings our WLServer assuming your system password is “secret”.
>java weblogic.Admin -url "http://127.0.0.1:7001" –username system -password secret PING 1 10
- A successful result of a PING should look like the following.
Sending 1 ping of 10 bytes.
RTT = ~20 milliseconds, or ~20 milliseconds/packet
• Other Admin commands follow a very similar format.
- You will have to have weblogic.jar in your classpath.
- You will be running weblogic.Admin using java.exe for all of these commands.
- You will be using the same format for entering password and username for most of the commands.
- After you get PING working the hard part is really done, all of the commands are easy when you get
the format.
- If you want detail on commands you can run, either type in “java weblogic.Admin usage” to see the
usage, or visit http://www.weblogic.com/docs51/admindocs/weblogicserver.html.
• Although we will talk briefly about the other Admin commands available, we will not give detailed
examples of each. Follow the PING procedure and use “usage” to trouble shoot any difficulty.
- LOCK requires a system administrator password. Locking WLServer disables logins.
- UNLOCK is just the opposite of Lock.
- HELP will do similar work to usage.
- LIST will list a JNDI context for you. We talk about JNDI in more detail and see an easier way to see
the JNDI tree a bit later.
- SERVERLOG will list the contents of the server log.
- LICENSES will list your license information
WebLogic Console
• Much of the work you can do from the command line is easier to work with in the Console.
• To open the WebLogic console you use your browser.
- The WebLogic console is a HTTP/HTML application that makes configuring your WLS more
accessible.
- The command line administration tools are still essential. Administrators often create scripts to do
simple but repetitive work.
- To access the console you will open a browser and point it to your WLS domain with a /console after it.
- Assuming some defaults the URL for the console looks like this.
http://localhost:7001/console
• To access the console you need to know the system password. Following our example above it’s
“secret” in this demo.
• The console when you first open it should look like this.
• The console is a central point to work with the configuration of your WLServer.
- The configuration information is actually stored for each domain you create.
- The configuration information for your WLServer is basically the whole config folder. This folder is
found under <Install directory>\wlserver…
- The config folder contains one folder for each domain you create in the WLServer.
- The configuration information for each domain is contained in a config.xml file in the domain folder.
- When you successfully boot up the server the server will create a copy of the config.xml file called
config.xml.booted, if any changes you make in the console break your server you can uses config.xml.booted
to “roll back” the changes.
• The console is a fairly familiar layout for a visual application.
- The left side basically represents a navigation of features.
- The right side is information about what is selected on the left.
• The console is a nice visual representation that makes configuration files easier to work with, and
provides a GUI for admin tasks.
- Many of the changes you will invoke with the console will just be changes to an xml file called config.
xml
- Also the Admin commands issued can be done in the console without prior knowledge of the arguments
or classes involved.
• To demonstrate how to the console directly manipulates an xml file let’s add a startup class.
• A startup class is a Java class that is run at the end of the startup procedure.
- Startup classes typically will be responsible for setting up initial resources not taken care of by
anything else.
- Startup classes have a counter class type called the Shutdown class. You can probably imagine what a
shutdown class is.
• To configure our startup class we will go to the console and navigate to startup/shutdown. mydomain
> Deployments > Startup & Shutdown.
• Select “Create a new Startup Class” which will lead you to a screen where you can put in a few pieces
of information.
- The name is just any text name you want to call this particular startup, think of it as an alias. These
name/aliases appear for all configuration options, so get comfortable with it immediately.
- The Classname is the full name of the class you will create, remember to include in your package name.
To demo it we will create sclose.wls.SCStartup.
- The arguments you define here will be passed into your class inside of a Hashtable. A sample
arguments might be “source=sclose.jdb.util.FinalClass,destination=log.admin”
- Select or deselect the checkbox to have the WLS startup dependant on successfully running your
startup class.
• You must assign a target to your startup class, so select the “targets” tab and move your targeted
server, or cluster to the right hand “Chosen” list.
• Changes to the startup classes, unlike most changes will require a reboot to work.
• To shutdown the server navigate to your server, then move to the monitoring tab and find a link called
“Shutdown this Server …”.
- It might take a minute to shutdown the server.
- You can shutdown the server using the weblogic.Admin class if you prefer.
- You could also write a script to shutdown the server.
• The next step in our creation of a startup class is to code the class.
- A startup class should implement the weblogic.common.T3StartupDef interface.
- Instead of implementing the T3StartupDef interface, your class can define a typical main method. If
you don’t implement the interface, the server will use introspection and call the main method instead.
- Your server must find the startup class, so you must place the resulting bytecode (.class file) in the
classpath used by WLServer.
• Creating a class the implements weblogic.common.T3StartupDef is simple.
package sclose.wls;
import java.util.Hashtable;
import java.util.Enumeration;
import weblogic.common.T3StartupDef;
import weblogic.common.T3ServicesDef;
public class SCStartup implements T3StartupDef{
public String startup(String name, Hashtable ht)throws Exception{
System.out.println("The virtual name of this class is " + name);
Enumeration enum = ht.keys();
while(enum.hasMoreElements()){
String key = (String)enum.nextElement();
System.out.println("Arg Name: " + key + " Arg Value: " + ht.get(key));
}
System.out.println("END OF STARTUP METHOD");
return "Output from SCStartup Class";
}
public void setServices(T3ServicesDef def){
System.out.println("IN SETSERVICES");
}
}
• Your startup class, since it implements T3StartupDef will need to override two methods defined in
T3StartupDef.
- The setServices method will be called before startup is called.
- The startup method will be called to do any processing needed.
- To get this code to compile you need to include weblogic.jar in your class path so it can find
T3StartupDef and T3ServiceDef.
• Before restarting WLS you will need to modify the classpath, the simplest way to get this done is to
modify the startWebLogic.cmd file.
- Find the set CLASSPATH command in startWebLogic.
set CLASSPATH=.;.\lib\weblogic_sp.jar;.\lib\weblogic.jar
- Change the command to include the root directory of where you compiled your Startup class.
set CLASSPATH=.;.\lib\weblogic_sp.jar;.\lib\weblogic.jar;c:\Java_Root
• If configured correctly you should see output from your startup class being run by WLS.
INSETSERVICES
The virtual name of this class is stevesStartup
Arg Name: horton Arg Value: hears.a.who
END OF STARTUP METHOD
• This output reflects information from multiple locations.
- INSETSERVICES and END OF STARTUP METHOD are direct System.out.println’s found in the
Startup method.
- The output also includes “horton”, “hears.a.who” and “stevesStartup” which are strings we added in
the console.
- The string “Output from SCStartup Class” which is returned from the startup method did not appear in
this text.
- The string returned from startup will appear in the log file, and can appear in the console if you wish,
but it is a lower priority message and by default the server will filter out lower priority messages.
- You can reset what messages go to the command line in the console. Select myserver and the Logging
tab and look for “Stdout severity threshold”
- The output in the <install directory>\wlserver\logs\weblogic.log. The name and location of the log file
is configured on the same tab as the severity. It is commonly named weblogic.log or mydomain.log.
<Apr 19, 2001 3:59:32 PM CDT> <Info> <WebLogicServer> <sclose.wls.SCStartup repo
rts: Output from SCStartup Class>
• The console provides easy to understand access to the config.xml file.
• If you look in the config.xml file found in
<install directory>\wlserver\config\mydomain.
• Looking at config.xml we will find some very familiar information.
<Application Deployed="true" Name="console" Path=".\config\mydomain\applications">
<WebAppComponent Name="console" Targets="myserver" URI="console.war"/>
</Application>
<StartupClass Arguments="horton=hears.a.who"
ClassName="sclose.wls.SCStartup" FailureIsFatal="true"
Name="stevesStartup" Targets="myserver"/>
<Security GuestDisabled="false" Name="mydomain"
PasswordPolicy="wl_default_password_policy" Realm="wl_default_realm"/>
- Notice the “horton” and “hears.a.who”. I doubt that these strings were added by anyone else.
- This is a snippet of config.xml, the whole document is much larger than 9 lines.
- Config.xml is a standard xml file, and as such is fairly human readable.
• Instead of using the console you can make changes to config.xml directly if you prefer, and you are
comfortable with xml.
• For more details on config.xml and all the options you can choose look at http://e-docs.bea.
com/wls/docs60/config_xml/overview.html, which has links to more information about this configuration file.
WebLogic Administration
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials