Using BEA WebLogic for Servlet and JSP Development · What is BEA WebLogic? BEA WebLogic is a...

Copyright DevelopIntelligence 2003 – 2008 :: http://www.DevelopIntelligence.com :: 303-395-5340

Using BEA WebLogic for Servlet and JSP Development


What is BEA WebLogic? BEA WebLogic is a certified J2EE complaint application server. Because it is certified in its compliance to the J2EE specification, it provides full enterprise container functionality. This includes Web Container functionality, Enterprise Java Bean container functionality, Java Naming and Directory Interface (JNDI) functionality, Java Messaging System (JMS) functionality, Java Web Services support, amongst others. Depending on the version of WebLogic you are using, you may have support for J2EE 1.3 (WLS 7.x) or J2EE 1.4 (8.x and 9.x). The most current product version is 9.0. However, we will be using 8.1 for this course.

Where can I get WebLogic? WebLogic is available as a purchasable product from BEA (http://www.bea.com). However, BEA does provide a free development or evaluation license to its WebLogic platform. Typically, you must register as a developer in their Dev2Dev community in order to download the WebLogic product.

Which WebLogic Product do I use? Like many companies, a product’s name eventually becomes a brand. WebLogic is no different. You will find WebLogic products named the WebLogic Platform, the WebLogic Server, WebLogic Integration Server, WebLogic Portal, WebLogic Workshop. We are only concerned with WebLogic Server. However, you may wish to download the WebLogic Platform which is a bundle of the Workshop and Server products.

Installing WebLogic Once you have downloaded the appropriate WebLogic product you will need to install it. Depending on the operating system you are using, the installation process may differ. The installation process outlined below is based on the x86 architecture running Windows XP Service Pack 2.

Typically when you install a J2EE application server, you will want to have a pre-existing Java Runtime Environment installed. Commonly, you will have both the JRE and the SDK installed. BEA has created their own implementation of the JRE and the SDK, called JRockit. JRockit is available for Windows 2000/XP and Linux.

BEA typically recommends you use JRockit in the production environmens when running the WebLogic Server. If you decide to adopt this suggestion, you will not have to install a pre-existing JRE. However, it is quite suitable for the development environment.


Installing WebLogic Using JRockit The following installation discussion is based on WebLogic 8.1 SP 5.

The easiest way to install WebLogic is to download the full installation. BEA provides both a network based installation and a standalone installation. The current version of the standalone installation is named platform815_win32.exe.

Upon double-clicking the installation executable, the BEA Installer should start.


Once you see the “welcome” screen, select the Next button to begin the installation. This will bring you to a license agreement. Depending on your legal expertise and comfort level with the license agreement, either agree with the terms and continue or disagree and cease the installation.

As part of the installation, you will need to create what is referred to as the BEA Home. The BEA Home directory is the root directory of the installation. Upon a successful installation, your actual WebLogic instance will be found in the BEA Home directory. Since we will be installing WebLogic from scratch, select the default location provided by the installer (c:\bea). Select the Next button to continue.


Once you have identified the BEA Home Directory, you need to choose which BEA products to install. You can either choose the default installation, which is the WebLogic Platform and includes WebLogic Server, WebLogic Workshop, WebLogic Portal, WebLogic Integration, or you can choose a custom installation.

For this class, all we need to install is WebLogic Server. We don’t need WebLogic Portal or WebLogic Integration. Since WebLogic Workshop simplifies development of J2EE applications for the WebLogic Server, we will also install it. As such, we will perform a Custom installation.


Select the Custom radio button and select the Next button. On the Choose Components screen deselect WebLogic Integration, WebLogic Portal, and Platform Samples and Utilities.

Proceed with the installation by selecting the Next button. You are about to finally begin the installation of the WebLogic Server product. It is typically a good practice to install the WebLogic Server product within the BEA Home directory. The installer will, by default setup the installation to follow this practice.


Before installing the actual product, the installer will ask you whether or not you would like to install the Node Manager Service. In the production environment, you would typically install WebLogic as a Windows Service, which would require the installation of the Node Manager Service. The Node Manager is an administration application or a utility that enables remote management and monitoring of WebLogic instances (or nodes). Since we are working in strickly a development environment, there is no need to incur the overhead of installing WebLogic as a managed node. As a note, if you know that you will eventually have your development instance managed as a node, you may want to install the service aspects initially, as setting this up later is a bit of a hassle. However, we are not going to do this for our development environment.

Once you select the Next button, the installation process will begin. Depending on your machine, this could take as few as 2 minutes or as much as 10 minutes. Sit back, read the marketing, and watch the progress bar.


That wasn’t too bad was it? Once the installation has completed, the installer then begins the configuration process. Using the installer to setup your WebLogic instance is by far the easiest and most straight forward way to perform the initial configuration. In order to perform this installer based configuration, you will need to run the Quickstart utility.


The Quickstart feature will enable you to explore WebLogic Workshop, read documentation about WebLogic Server or JRockit, and most importantly Create a new domain configuration.

Once the Quickstart window appears, select the Create a new domain configuration option. This will launch the BEA WebLogic Configuration Wizard. The wizard will step us through the configuration of our WebLogic domain. A domain is a representation of a collection of WebLogic instances and resources that can be managed as a single unit. In our environment, we will have a single domain with a single instance. In a production environment, however, you may have a single domain with many instances (or nodes).


After selecting the Next button, you will be able to select a template or skeleton to use in building the domain creation and configuration. There are two options that you may consider when building a J2EE application in the WebLogic environment. First, if you are going to utilize the WebLogic Workshop product, you may want to consider creating a domain that is configured to tightly integrate within WebLogic Workshop. This is useful for things like server-based debugging, tool based deployment, etc. The second option, however, is the more standard way to set up a new domain. It is a bit more standard in that many developers use other development tools, like Eclipse or IntelliJ to build their J2EE solutions. For this class, we will use the Basic WebLogic Server Domain.


Once you have selected the Basic WebLogic Server Domain, you will need to choose what type of configuration process to go through, either Express or Custom. For our needs, the express option is sufficient. However, if you wanted to create an instance that was a managed node, or you wanted to setup resources (like connection pools and datasources) you would choose the custom option.

It is always a good idea to specify a distinct password for administrative purposes. The username you specify along with the password will be used to administer WebLogic through the Administration Console. The admin console, by default, is accessible at the path http://…/console. Define a password and then select the Next button.

Once you have defined the administration information, the next part of the configuration deals with the runtime mode and the JVM you will be using. As mentioned earlier, you may want to pre-install the version of J2SE you desire. If you do not perform that installation, two SDKs are installed for you as part of the WebLogic Server install. They are JRockit and Sun’s JDK, both J2SE version 1.4.2.

WebLogic has the ability to run in two different modes. A development mode and a production mode. The development mode has more runtime overhead than the production mode and is a


little looser in terms of security. It is the mode that you should choose for development. The overhead comes from a polling strategy that deals with application deployment.

You will notice two SDK choices on the right. BEA confesses JRockit may not be the best for development as it has slower start up times. On a fast machine, you will probably notice no difference between JRockit or Sun’s JVM from a development perspective. It is always worthwhile to perform a tuning exercise as your application reaches maturity. As part of the tuning exercise, you should test your application on many different JVMs, against different memory settings, and with different garbage collection strategies.

Choose either SDK and select Next.

The last set in the configuration wizard is to create a server, typically referred to as the instance, within a domain. The last screen allows you to specify where you would like the domain to be created. The directory structure you choose, once created, will contain start and stop scripts, configuration scripts, as well as your deployments. For this class, change the Configuration Name of the domain to 902_domain. The Configuration Location path should change automatically based on the domain name change.


Select Create, sit back, and wait for it to complete.


Exit out of the Configuration Wizard by selecting the Done button. Also, close the Quickstart window.

Exploring the Installation Once you have finished the installation process, it is important to understand what files have been installed and where they are located. Based on our configuration during the installation wizard, our BEA Home is located at c:\bea. All of the products selected as part of the installation process are installed, in some form or fashion, in this directory. Typically, the products are installed as subdirectories of the BEA Home.

In our case, the wizard “installed” two software development kit environments. Remember that we were given an option on which SDK to use when creating our WebLogic instance. Despite our choice, the wizard installs both SDKs. JRockit is located at c:\bea\jrockit81sp5_142_08 while Sun’s SDK is located at c:\bea\jdk142_08.

The wizard also installed a license key for our instance. In our case, the license is a developer license. Typically, developer licenses restrict the WebLogic server, not in functionality, but in simultaneous client access. In a typical development world, this would be of no concern as you will usually be the only developer against the instance. The license is located at c:\bea\license.bea.

You may notice, there is also c:\bea\UpdateLicense.cmd. This program is used to install a purchased license from BEA.


The two other subdirectories of interest to us are c:\bea\weblogic81 and c:\bea\user_projects. The subdirectory weblogic81 contains the WebLogic Platform. Located in this directory you will find WebLogic Workshop (c:\bea\weblogic81\workshop) as well as the subdirectories for the platform itself. In particular, the subdirectory server (c:\bea\weblogic81\server) contains the core modules to make the server work, such as the bin directory.

The c:\bea\weblogic81\server directory contains templates used to build domain instances, as well as shared repositories for libraries.


As a developer, we also need to be interested in the c:\bea\user_projects directory. As part of the Quickstart wizard, we created a new instance defined by a servername and a domain. For each domain you create, you will find a subdirectory within c:\bea\user_projects\domains. In our case, there is only one domain, the one we created during the Configuration Wizard, called 902_domain

.

The Configuration Wizard uses the files located in the server directory as templates to create a domain specific server instance. As you explore the 902_domain subdirectory, you will notice configuration files (config.xml), log files, scripts, and a few subdirectories. Because each domain is its own instance, each instance has its own configuration, logging, deployments, and control scripts. As a quick note, you will not find any common or lib directories in your instance. The intent is that all applications deployed to your instance are self-contained, and therefore the instance should not need additional libraries installed.


Configuring WebLogic Configuration of WebLogic is typically done on the instance level. In our case, it should be done within the 902_domain. All instance level configuration will occur within either setEnv.cmd (to setup the appropriate environment variables, like JVM vendor, classpath, etc. – you shouldn’t have to modify this for the class), boot.properties (to adjust username and password), and config.xml (contains a proprietary description of resources deployed in your instance).

In some cases, you may need to modify the environment variables beyond what is allowed in the setEnv.cmd file. For example, if you wanted to adjust heap settings or memory settings. Though you could adjust (actually add) parameters for those in the setEnv.cmd file, you could also modify the startWebLogic.cmd file. As tuning is beyond the scope of this course further information can be found on BEA’s website. For this class, the Configuration Wizard created satisfactory setEnv.cmd and startWebLogic.cmd files for us.

Without turning this into an administration course, it is worthwhile to touch on some of the information found in the config.xml file. In particular, from a configuration perspective, you may need to adjust the information found in the <Server> … </Server> tags. In particular, you may want to adjust the ListenPort associated with your server. If you were to look at the config.xml file generated as part of the Configuration Wizard, you would find a <Server> tag similar to this:

<Server ListenAddress="" ListenPort="7001" Name="myserver" NativeIOEnabled="true" ReliableDeliveryPolicy="RMDefaultPolicy" ServerVersion="8.1.5.0"> <SSL Enabled="false" HostnameVerificationIgnored="false" IdentityAndTrustLocations="KeyStores" Name="myserver"/>


</Server>

In order for the labs to work properly for this course, we will need to adjust the config.xml file and change the value of the ListenPort attribute from 7001 to 8080. Obviously, you should only modify this while the server is not running.

Further on down the config.xml file, you may notice tags used to “declare” other resources configured within your server. For example, if you have set up a JDBC connection pool or a JDBC datasource, you would find those configuration entries. In our case, the Express Configuration Wizard does not setup any additional resources. Choosing the Custom option and creating those resources as part of the Wizard process would generate entries in the config.xml file.

Typically, the last thing you will find in config.xml are entries “declaring” deployments. All deployments are declared in the config.xml file to address robustness across restarts. As you go through the labs, any deployments you make will show up in an <Application> . . . </Application> tag.

WebLogic Server Administration Console Most folks have moved beyond text based configuration of servers to graphical user interfaced based tools. WebLogic includes an administration console to simplify configuration and administration of the server. Assuming an Express creation of an instance (which is what we did), the administration console can typically be found (on your local machine) at http://localhost:7001/console. You will be prompted for the username and password you specified as part of the Configuration Wizard. Since we have modified the ListenPort associated with our instance to 8080, for the class you can find the console at http://localhost:8080/console.


Once you log in, you will find the console divided into two sections. On the left hand side, you will observe a navigation tree. On the right hand side, you will find options associated with a selected navigation item.

So, we know how to adjust the configuration of the instance via the text files, but let’s assume you wanted to adjust the ListenPort associated with the domain via the console. You could click the link “Servers” under the section entitled Domain Configuration. Similarily, you could select the navigation item (on the left hand side) called myserver under the Servers node. In both cases, the content of the right frame would change based on your selection.


That simple discussion should provide a starting point on how to navigate around the administration console. For futher information on how to administer BEA WebLogic refer to the BEA website.

As a note, anytime you change a property within the administration console that has a icon, a restart is required in order for the change to take effect.


Controlling WebLogic There are two main ways to control your WebLogic instance. One way is from the console. If you were to explore the console, you would find the ability to shutdown an already running server. If, as part of your configuration, you configured the instance as a managed node, you would also be able to start the server using the administration console.

The second way to control the WebLogic instance is to use the scripts located in the 902_domain directory. In that directory, you will find both start and stop scripts.


Starting WebLogic Using startWeblogic.cmd In most development environments, instances are not configured as managed nodes. As a

result, the initiation or starting of the WebLogic instance must be performed through the startWebLogic.cmd script. There are two ways to invoke this start script, both of which yield the same results.

In Windows fashion, there is a Start menu shortcut to the start the domain specific instance.

Selecting this shortcut will open a CMD (Dos-Shell) and invoke the startWebLogic.cmd script within that shell.

The other option, is to manually open a CMD and navigate to the c:\bea\user_projects\domains\902_domain directory. Within this directory, you can either invoke the script within the existing shell by typing startWebLogic or you can invoke the script in another shell by typing start startWebLogic.

The method you choose does not effect the starting of the WebLogic instance, so choose the option that is most comfortable to you. Once you invoke the script, WebLogic will start and log its startup information to the shell.


It is worthwhile to examine the output of the startWebLogic script. Depending on the performance of your machine, this may go by quickly. However, if you were to dissect the output you should see information noting the name of the server (myserver), the name of the domain (902_domain), the log file for the server (c:\bea\user_projects\domains\902_domain\myserver\myserver.log), the listening address (*.* -- in this case, all addresses associated bound to the network interface) and port (8080). For our class, in a successful startup you should not see any exceptions and should see “listening on port 8080”.


Stopping WebLogic using stopWebLogic.cmd As mentioned earlier, one way to stop the WebLogic instance is to use the Administration Console. However, in quick iterative development cycles, it may be easier to stop the instance using the command line stopWebLogic.cmd script. There is no Start menu short cut to invoke this script, so you will need to open a CMD and navigate to the c:\bea\user_projects\domains\902_domain directory. Within that directory, you shutdown the running server by simply typing stopWebLogic.

Upon invoking this script, you may receive an error. Remember, our start and stop scripts were generated by the Configuration Wizard. The Configuration Wizard automatically chose the port 7001 for our instance. As such, it generated a stop script to access a server instance running on that predetermined port. Since we changed the ListenPort attribute in the config.xml file (or through the administration console) our stop script is no longer valid. Bummers.

To resolve this problem, open the c:\bea\user_projects\domains\902_domain\stopWebLogic.cmd file in your favorite text editor. Our classroom is setup with TextPad, so you may want to use that.

A simple search and replace of 7001 with 8080 should resolve the problem. If you don’t trust the search and replace feature of your text editor, search for the line that set ADMIN_URL=t3://localhost:7001 and change the port to 8080.


Now that we have brought our stop script in line with our latest configuration, you can stop the server by simply running stopWebLogic.

The shell in which you invoked stopWebLogic should generate the following output: Server “myserver” was force shutdown successfully . . .

Also, the shell containing the output from the startWebLogic script should show that the shutdown sequence initiated and completed.


Server Logging There are multiple types of logging that occur by default within the WebLogic server. There is logging of domain startup and shutdown. There is logging of client access, typically HTTP access logs. And finally, there is server level logging, typically containing deployment / undeployment as well as application specific log messages.

Domain generated logging can be found in: C:\bea\user_projects\domains\902_domain\902_domain.log

HTTP logs can be found in: C:\bea\user_projects\domains\902_domain\myserver\access.log

Server level logging (and application logging) can be found in: C:\bea\user_projects\domains\902_domain\myserver\myserver.log

Initially, WebLogic is setup to perform logging based on some predetermined default values. Most aspects of the logging behavior can be adjusted through the administration console. Within the Administration Console, you can adjust the logging properties for the domain, HTTP, the server, along with JDBC. In the context of server logging, you can change properities like the location of the log file, logging level, rotation strategy, etc.


Installing 3rd Party Libraries (JARs) Per the J2EE Specification, all deployment artifacts should be self contained, including WAR files. Within a WAR, you would place any required 3rd party libraries in JAR format within the WEB-INF/lib directory.

In some cases, however, it is not possible to place a 3rd party library in a WAR file. A common example of this is a 3rd party library that utilizes Java Native Interfaces (JNI) to access some C or C++ component. Due to the security constraints in which WARs run (sandboxes if you will), WARs aren’t typically allowed to load JNI libraries.

Likewise, you may find yourself deploying many WARs, all which contain the same 3rd party library. In this scenario, the class loading mechanism of the server may be smart enough to load the library only once. However, this would be a server vendor optimization and may not be specification endorsed. The most likely result of a scenario like this is that your 3rd party library would be loaded into the JVM for each WAR you deploy. This can have both a drastic impact on performance and memory utilization. A real-world scenario is in the context of JDBC drivers.


In either scenario, the way to resolve this problem and “install” the 3rd party library is add the JAR file containing the 3rd party library to the classpath of your server. There are many ways to modify the classpath of the server. One way is to modify the script setEnv.cmd. In this script, add the 3rd party JAR to the CLASSPATH property. If you adopt this route, you will need to run setEnv.cmd prior to running the startWebLogic.cmd script.

The second route is to modify c:\bea\common\bin\commEnv.cmd. In this file, which is shared across all instances you ever start, you would modify the CLASSPATH property, adding your 3rd party library to the path.

The third route, is to modify the startWebLogic.cmd script itself. If you were to modify this file, again you would modify the CLASSPATH property and place your 3rd party library within that path.

For our class, we are using MySQL as our database. MySQL provides a JDBC driver called Connector/J. The most current release of Connector/J is 3.1.x. Connector/J can be downloaded from the MySQL website.

Once you have downloaded the MySQL Connector/J, edit the startWebLogic.cmd file and add mysql-connector-java-3.1.11-bin.jar to the CLASSPATH entry, make sure to include the absolute path to the actual file.


Deploying Applications Like most things, there are multiple ways to deploy applications to WebLogic. In a development environment, the most common way to deploy applications is through some form of automated build script. The most common automated build tool for Java is ANT. Most application servers have ANT tasks that enable the automated deployment. However, you may not need to use an application server vendor specific ANT task to perform automated deployment.

Many J2EE servers, WebLogic included, can function in a development mode. In this mode, the J2EE server polls a deployment directory for new deployments. When the server finds a new deployment archive, it automatically deploys the archive to the server. In our class, we will be using ANT to copy our WAR file to the deployment directory. The deployment directory within WebLogic is always named applications and can be found under your domain. Specifically, c:\bea\user_projects\domains\902_domain\applications.

If you want complete control over deployment and undeployment of an application, turn to the WebLogic administration console. Within the WebLogic administration console, you can deploy new applications and undeploy existing applications. The console provides a graphical deployment environment in which you can modify, at some level, information about your application as part of the deployment process.

Whether applications are deployed by copying the deployment archive (a WAR, EJB Jar, or an EAR) to the applications directory or through the console, all deployed applications will appear and can be managed through the console.

Let’s walk through the two different deployment scenarios for the HelloWorldServlet exercise found on Page 3 of the text. As the book mentions, creating the HelloWorldServlet application and deploying it is a two step process. However, the true cycle should be build, deploy, validate, test. Below these four steps are outlined.

Automated Deployment

Step 1 – Build Build the deployment artifact by running asant in the DOS shell within the c:\902_Files\examples\HelloWorldServlet directory. Upon a successful build, you should notice that the last step in the build process is the creation of the deployment artifact. The deployment artifact for this example is called helloWorldServletApp.war. It is located in the c:\902_Files\examples\HelloWorldServlet\dist.


Step 2 – Deployment Deploy the deployment artificat (helloWorldServletApp.war) to the applications directory within our 902_domain using the asant deploy command. The deploy task copies the WAR file into the C:\bea\user_projects\domains\902_domain\applications directory. At this point, WebLogic will automatically detect the introduction of a new application deployment artifact and perform an automatic deployment (sometimes referred to as a Hot Deployment). This behaviour is a side-effect of running in Development Mode.

Step 3 – Validating Deployment It is typically a good idea to validate whether or not WebLogic deployed your application before beginging your testing procedures. Since we are working in the command-line world, we can determine whether WebLogic deployed our application by examing (with the server running) the server log, c:\bea\user_projects\domains\902_domain\myserver\myserver.log. In this logfile, you should find an entry that looks something like this:


####<Nov 1, 2005 9:56:45 AM MST> <Info> <Deployer> <latitude> <myserver> <ExecuteThread: '4' for queue: 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-149074> <Successfully completed deployment task: [Deployer:149026]Deploy application _appsdir_helloWorldServletApp_war on myserver.>

Notice within this log entry, the name of our deployment artifact has been renamed to appsdir_helloWorldServletApp_war, this is a result of “deploying” our application to the applications directory.

If the myserver.log file is too confusing, a quick glance at the config.xml file will also note that your application was deployed successfully.

Step 4 – Testing the Application Once we have validated the deployment of our application, we are ready to test it. Referring again to Page 3 of our text, we can test our application by browsing to http://localhost:8080/helloWorldServletApp/hello.


Console Deployment Console deployment is a little more involved than the automated deployment. However, the first step, build, is the same. As such, we will pick up with Step 2.

Step 1 – Build Same as above.

Step 2 – Deployment This is where our paths diverge. Console deployment is a multiple step process. The process noted below assumes you have successfully logged into the administration console. Depending on the type of application you are trying to deploy, you will need to select the appropriate navigation sub-node from the Deployments node. In our case, we are working only with Web Application Modules.


Step 2a – Selecting a Web Application Module for Deployment Clicking the link entitled “Deploy a new Web Application Module” in the browser will start the deployment process. In order to deploy a module using the console, you must navigate the filesystem to the location in which the module exists. In our case, the module exists in c:\902_Files\examples\HelloWorldServlet\dist.


Step 2b – Targeting the Web Application Module Once you have navigated to the appropriate directory containing your deployment artifact (helloWorldServletApp.war), you must target the module for deployment. In our environment, this is a relatively straightforward process as we only have one server configured, myserver. In a production or a larger scale environment, the “Target Module” functionality would allow you target the deployment to local or remote servers.

Notice, there is not much targeting you can do in our environment. Again, this is due to the fact that we only have one server configured. When you are ready to deploy the application, select the Deploy button.


Step 3 – Validating Deployment Validating the deployment within the console is more straightforward than from the command line environment. However, it is important to note, that even though we deployed the application using the console we could validate the deployment from the command line, looking at the same two files mentioned above.

After selecting the Deploy button, the console will refresh and display the Deploy tab associated with Web Applications. In this tabbed view, you will find a table that lists all of the current deployments, along with where they are deployed, their health, and the ability to control the deployments.

More information about the deployments can be obtained by clicking on the Web Application Modules node in the navigation tree.


Step 4 – Testing the Application Testing the deployment is no different than mentioned above.


Application Redployment It is common during the lifecycle of an application to either undeploy or redeploy the application to the server. Some J2EE servers will allow you to perform hot reployments by changing the contents of the deployment archive. WebLogic, in Development Mode, supports this fully.

In the context of our class, any time you modify the source code associated with your web application, you will want to create a new deployment artifact. Once the deployment artifact has been created, you can deploy the new artifact by invoking asant deploy from the command line or by selecting the Redeploy button within the console.

In both cases, WebLogic will remove the old deployment and end the lifecycle of that application. It will then deploy the new (updated) application and start its lifecycle.

As a note, the console also provides a Stop functionality. This does not delete the deployment from the configuration, rather, it just inactivates the deployment, or ends its lifecycle.

Application Undeployment Removing an application from a J2EE server, or undeployment, varies. In some servers, you can delete the deployment artifact from the deployment directory and the server will automatically undeploy the application. In other servers, you need to go through a formal undeployment process whether that is script or console based.


Console Based Undeployment Within WebLogic, console based undeployment is a relatively straightforward process. By selecting the Web Application Modules navigation node, you will find a list of deployed applications. You should recognize the universal delete icon in the table, a trash can. Clicking on this will stop the application, as well as remove it from the configuration, thus performing an undeployment.

Select the “Trash”. Confirm the deletion of the application.


Continue back to the “Deployment” screen.

You should see some changes in the navigation tree based on your actions. In particular, the deployment (or application) no longer exists as a navigation node. As a note, you can also right click on an application node and select the “delete” menu item. The results are the same.

Command Line Based Undeployment WebLogic does support hot undeployments outside of the console. To undeploy an application from the instance, simply delete the artifact from the applications directory. You can do this either using the DOS shell or Windows Explorer. Since you aren’t looking at the console to see if the application was undeployed, you should refer to the myserver.log file as well as the config.xml file to validate the undeployment worked successfully.

Using BEA WebLogic for Servlet and JSP Development · What is BEA WebLogic? BEA WebLogic is a...

Documents

Transcript of Using BEA WebLogic for Servlet and JSP Development · What is BEA WebLogic? BEA WebLogic is a...