|
|
|
|
| |
Packaging and Deploying WebLogic Server Applications
The following sections describe how to package and deploy WebLogic Server applications:
WebLogic Server applications are packaged in a standard way, defined by the J2EE specifications. J2EE defines component behaviors and packaging in a generic, portable way, postponing run-time configuration until the component is actually deployed on an application server.
J2EE includes deployment specifications for Web applications, EJB modules, Enterprise applications, and Client applications. J2EE does not specify how an application is deployed on the target server-only how a standard component or application is packaged.
For each component type, the specifications define the files required and their location in the directory structure. Components and applications may include Java classes for EJBs and servlets, Web pages and supporting files, XML-formatted deployment descriptors, and JAR files containing other components.
An application that is ready to deploy on WebLogic Server contains additional, WebLogic-specific deployment descriptors and, possibly, container classes generated with the WebLogic EJB, RMI, or JSP compilers.
A file created with the Java
JAR files are convenient for packaging components and applications for distribution. They are easier to copy, they use up fewer file handles than an exploded directory, and they can save disk space with file compression. If your Administration Server manages a domain with multiple WebLogic Servers, you can only deploy JAR files, because the Administration Console does not copy expanded directories to managed servers.
The
The most common usages of the
The first flag specifies the operation:
Components and applications have deployment descriptors-XML documents-that describe the contents of the directory or JAR file. Deployment descriptors are text documents formatted with XML tags. The J2EE specifications define standard, portable deployment descriptors for J2EE components and applications. BEA defines additional WebLogic-specific deployment descriptors required to deploy a component or application in the WebLogic Server environment.
Table 3-1 lists the types of components and applications and their J2EE-standard and WebLogic-specific deployment descriptors.
When you package a component or application, you create a directories to hold the deployment descriptors-
If you receive a J2EE-compliant JAR file from a developer, it already contains J2EE-defined deployment descriptors. To deploy the JAR file on WebLogic Server, you must extract the contents of the JAR file into a directory, add the required WebLogic-specific deployment descriptors and any generated container classes, and then create a new JAR file containing the old and new files.
To stage and package a Web application:
Note: See Classloader Overview to understand how the WebLogic Server class-loading mechanism affects EJB references from servlets within the same application.
Note: See Writing Web Application Deployment Descriptors for help creating deployment descriptors for Web applications.
jar cvf myapp.war -C staging-dir.
The resulting
Packaging Enterprise JavaBeans
You can stage one or more enterprise beans in a directory and package them in an EJB JAR file.
To stage and package an enterprise bean:
Note: See "Programming WebLogic EJB" for help compiling enterprise beans and creating EJB deployment descriptors.
jar cvf jar-file.jar -C staging-dir .
This command creates a
The
Enterprise beans require container classes, classes the WebLogic EJB compiler generates to allow the bean to deploy in a WebLogic Server. The WebLogic EJB compiler reads the deployment descriptors in the EJB JAR file to determine how to generate the classes. You can run the WebLogic EJB compiler on the JAR file before you deploy the beans, or you can let WebLogic Server run the compiler for you at deployment time. See Programming WebLogic EJB for help with the WebLogic EJB compiler.
Packaging Enterprise Applications
An Enterprise archive contains EJB and Web modules that are part of a related application. The EJB and Web modules are bundled together in another JAR file with an
The
Here is the
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD
J2EE Application 1.2//EN'
'http://java.sun.com/j2ee/dtds/application_1_2.dtd'>
<application>
<display-name>estore</display-name>
<description>Application description</description>
<module>
<web>
<web-uri>petStore.war</web-uri>
<context-root>estore</context-root>
</web>
</module>
<module>
<ejb>petStore_EJB.jar</ejb>
</module>
<security-role>
<description>the gold customer role</description>
<role-name>gold_customer</role-name>
</security-role>
<security-role>
<description>the customer role</description>
<role-name>customer</role-name>
</security-role>
</application>
To stage and package an Enterprise application:
jar cvf application.ear -C staging-dir .
The resulting
Resolving Class References Between Components
Your applications may use many different Java classes, including enterprise beans, servlets and JavaServer Pages, startup classes, utility classes, and third-party packages. WebLogic Server deploys applications in separate classloaders to maintain independence and to facilitate dynamic redeployment and undeployment. Because of this, you need to package your application classes in such a way that each component has access to the classes it depends on. In some cases, you may have to include a set of classes in more than one application or component. This section describes how WebLogic Server uses multiple classloaders so that you can stage your applications successfully.
A classloader is a Java class that locates and loads a requested class into the Java virtual machine (JVM). A classloader resolves references by searching for files in the directories or JAR files listed in its classpath. Most Java programs have a single classloader, the default system classloader created when the JVM starts up. WebLogic Server creates additional classloaders when it deploys applications because these classloaders can be destroyed in order to undeploy the application. This allows WebLogic Server to redeploy modified applications without having to restart the server.
Classloaders are hierarchical. When you start WebLogic Server, the Java system classloader is active and is the parent of all subsequent classloaders that WebLogic Server creates. A classloader always asks its parent for a class before it searches its own classpath, but a parent classloader does not consult its children. Because the search only proceeds upwards in the classloader hierarchy, this also means that a child classloader cannot locate classes on a sibling's classpath.
The search protocol also clarifies how duplicate classes are handled in Java. Classes located in the Java system classpath always have precedence over any class with the same name in a child classloader's classpath. Because of this, you should avoid placing application classes in the Java system classpath before you start WebLogic Server. The classloader created at startup time cannot be destroyed, so any classes it contains cannot be redeployed without restarting WebLogic Server.
About Application Classloaders
When WebLogic Server deploys an application, it creates two new classloaders: one for EJBs and one for Web applications. The EJB classloader is a child of the Java system classloader and the Web application classloader is a child of the EJB classloader. This allows classes in a Web application to locate EJB classes, but EJB classes cannot locate Web application classes. A positive side-effect of this classloader hierarchy is that it allows servlets and JSPs direct access to EJB implementation classes. WebLogic Server can bypass the intermediate RMI classes because the EJB client and implementation are in the same JVM.
If your application includes servlets and JSPs that use enterprise beans:
Although you could deploy the
Packaging Common Utilities and Third-Party Classes
If you create or acquire utility classes that you will use in more than one application, you must package them with each application. Alternatively, you could add them to the Java system classpath by editing the
Classes that WebLogic Server uses during startup must be in the Java system classpath. For example, JDBC drivers used for connection pools must be in the classpath when you start WebLogic Server. Again, if you need to modify classes in the Java system classpath, or modify the classpath itself, you will have to restart WebLogic Server.
Handling Interactions Between Startup Classes and Applications
Startup classes are classes you create that WebLogic Server executes at startup time. Startup classes are located by the Java system classpath, so you must put them in the system classpath before you start the server. Also, any classes they require must be included in the system classpath.
If a startup class uses application classes (such as EJB interfaces) you will also have to add those classes to the WebLogic Server startup classpath. Unfortunately, this means that you cannot modify those classes without restarting the server.
Startup classes that use application objects must wait for WebLogic Server to finish deploying the applications before they attempt to access the application objects. For example, if a startup class uses EJBs, you must include the home and remote interfaces in the system classpath, and you must ensure that the startup class does not create any EJB instances until WebLogic Server has finished deploying the EJB application.
The Pet Store application has a startup class that demonstrates one method a startup class can use to wait for applications to finish deploying. The
Here is an excerpt from that class to show how this works:
while (loop) {
try {
socket = new Socket(host, new Integer(port).intValue());
socket.close();
//launch browser
String[] cmdArray = new String[3];
cmdArray[0] = "beaexec.exe";
cmdArray[1] = "-target:browser";
cmdArray[2] = "-command:\"http://"+host+":"+port+"\"";
try {
Process p = Runtime.getRuntime().exec(cmdArray);
p.getInputStream().close();
p.getOutputStream().close();
p.getErrorStream().close();
}
catch (IOException ioe) {
}
loop = false;
} catch (Exception e) {
try {
Thread.sleep(SLEEPTIME); // try every 500 ms
} catch (InterruptedException ie) {}
finally {
try {
socket.close();
} catch (Exception se) {}
}
}
}
If the system fails to create a socket, or if the BEA-supplied
Deploying Applications and Components
You can deploy an EJB JAR, Web application, or Enterprise application by using the Administration Console or the
The
Note: If you have a single WebLogic Server, you can deploy applications and components by copying them to the server's
Using the Administration Console
To deploy an application using the Administration Console:
This copies the file to the Administration Server's
Depending on your choices, you may need to restart WebLogic Server. The Administration Console displays a restart message in the right pane.
Using the weblogic.deploy Command-Line Utility
The weblogic.deploy command-line utility allows you to deploy, undeploy, update, and list components on an Administration Server-tasks you can accomplish interactively using the Administration Console. The
See the documentation for weblogic.deploy in the Administration Guide for syntax and usage for this command line-utility.
Packaging and Deploying Client Applications
WebLogic Server applications written in Java run in a JVM on a client machine. The client JVM must be able to locate the Java classes you create for your application and any Java classes your application depends upon, including WebLogic Server classes. This usually means distributing the
You may also want to package a Java Runtime Environment (JRE) with a Java client application.
You can stage a client application by copying all of the files required on the client into a directory and bundling the directory up in a
The top level of the client application directory can have a batch file or script to start the application. Make a
Although not required for WebLogic Server applications, J2EE includes a standard for deploying client applications. A J2EE Client application module is packaged in a
A standard deployment descriptor from Sun is used for J2EE clients and a supplemental deployment descriptor contains additional WebLogic-specific deployment information.
See Client Application Deployment Descriptor Elements for help with these deployment descriptors.
On the client, the
java weblogic.ClientDeployer ear-file client
The ear-file argument is an expanded directory, or Java archive file with an
java appclient.ClientDeployer app.ear client
In this example, the
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|