|
|
The following sections describe how to create and configure Web application resources.
Web applications use a standard directory structure defined in the J2EE specification. You can deploy a Web application as a collection of files that use this directory structure, known as exploded directory format, or as an archived file called a WAR file. BEA recommends that you package and deploy your exploded Web application as part of an Enterprise application. This is a BEA best practice, which allows for easier application migration, additions, and changes. Also, packaging your Web application as part of an Enterprise application allows you to take advantage of the split development directory structure, which provides a number of benefits over the traditional single directory structure.
The WEB-INF directory contains the deployment descriptors for the Web application (web.xml and weblogic.xml) and two subdirectories for storing compiled Java classes and library JAR files. These subdirectories are respectively named classes and lib. JSP taglibs are stored in the WEB-INF directory at the top level of the staging directory. The Java classes include servlets, helper classes and, if desired, precompiled JSPs.
All servlets, classes, static files, and other resources belonging to a Web application are organized under a directory hierarchy.
DefaultWebApp/
DefaultWebApp, under user_domains/mydomain/applications.
web.xml file are mapped to resources residing elsewhere in WebLogic Server. This file is also used to define JSP and HTTP session attributes.
The entire directory, once staged, is bundled into a WAR file using the jar command. The WAR file can be deployed alone or as part of an Enterprise application (recommended) with other application components, including other Web applications, EJB components, and WebLogic Server components.
JSP pages and HTTP servlets can access all services and APIs available in WebLogic Server. These services include EJBs, database connections through Java Database Connectivity (JDBC), JavaMessaging Service (JMS), XML, and more.
The WEB-INF directory is not part of the public document tree of the application. No file contained in the WEB-INF directory can be served directly to a client by the container. However, the contents of the WEB-INF directory are visible to servlet code using the getResource and getResourceAsStream() method calls on the ServletContext or includes/forwards using the RequestDispatcher. Hence, if the application developer needs access, from servlet code, to application specific configuration information that should not be exposed directly to the Web client, the application developer may place it under this directory.
Since requests are matched to resource mappings in a case-sensitive manner, client requests for ‘/WEB-INF/foo’, ‘/WEb-iNf/foo’, for example, should not result in contents of the Web application located under /WEB-INF being returned, nor any form of directory listing thereof.
The following is an example of a Web application directory structure, in which myWebApp/ is the staging directory:
myWebApp/
WEB-INF/
web.xml
weblogic.xml
lib/
MyLib.jar
classes/
MyPackage/
MyServlet.class
index.html
index.jsp
The following steps summarize the procedure for creating a Web application as part of an Enterprise application using the split development directory structure. See “Creating a Split Development Directory for an Application, “Building the Applications, and “Deploying the Application in Developing Applications with WebLogic Server.
You may want to use developer tools included with WebLogic Server for creating and configuring Web applications. See Web Application Developer Tools.
application.xml and weblogic-application.xml) in the META-INF\ directory. See
“Enterprise Application Deployment Descriptors in
Developing Applications with WebLogic Server. \src\myEAR\myWebApp\images\myimage.jpg
\src\myEAR\myWebApp\index.html
Once you have set up your directory structure, you create the build.xml file using the weblogic.BuildXMLGen utility.
| Note: | The wlpackage Ant task places compiled versions of your Java source files in the build directory. For example: /build/myEAR/myWebApp/classes. |
You construct the URL that a client uses to access a Web application using the following pattern:
http://hoststring/ContextPath/servletPath/pathInfo
hoststring
ContextPath
servletPath
pathInfo
If you are using virtual hosting, you can substitute the virtual host name for the hoststring portion of the URL.
WebLogic Server supports two methods for configuring virtual hosts for Web applications:
The following is an example of how to configure a channel-based virtual host:
<VirtualHost Name="channel1vh" NetworkAccessPoint="Channel1" Targets="myserver"/>
<VirtualHost Name="channel2vh" NetworkAccessPoint="Channel2" Targets="myserver"/>
Where Channel1 and Channel2 are the names of NetworkAccessPoint configured in the config.xml file. NetworkAccessPoint represents the dedicated server channel name for which the virtual host serves HTTP requests. If the NetworkAccessPoint for a given HTTP request does not match the NetworkAccessPoint of any virtual host, the incoming HOST header is matched with the VirtualHostNames in order to resolve the correct virtual host. If an incoming request does not match a virtual host, the request will be served by the default Web server.
The following is an example of how to configure a host-based virtual host:
<VirtualHost Name="cokevh" Targets="myserver" VirtualHostNames="coke"/> <VirtualHost Name="pepsivh" Targets="myserver" VirtualHostNames="pepsi"/>
A Web application component can be targeted to servers and virtual hosts using the WebLogic Administration Console.
If you are migrating from previous versions of WebLogic Server, note that in the config.xml file, all Web application targets must be specified in the targets attribute. The targets attribute has replaced the virtual hosts attribute and a virtual host cannot have the same name as a server or cluster in the same domain. The following is an example of how to target a Web application to a virtual host:
<AppDeployment name="test-app" Sourcepath="/myapps/test-app.ear">
<SubDeployment Name="test-webapp1.war" Targets="virutalhost-1"/>
<SubDeployment Name="test-webapp2.war" Targets="virtualhost-2"/>
...
</AppDeployment>
Servlets, Context Listeners, and Filters are loaded and destroyed in the following order:
Servlets and filters are loaded in the same order they are defined in the web.xml file and unloaded in reverse order. Context listeners are loaded in the following order:
A J2EE Web application library is a standalone Web application module registered with the J2EE application container upon deployment. Using WebLogic Server 9.2, multiple Web applications can easily share a single Web application module or collection of modules.
A Web application may reference one or more Web application libraries, but cannot reference other library types (EJBs, EAR files, plain JAR files).
Web application libraries are Web application modules deployed as libraries. They are referenced from the weblogic.xml file using the same syntax that is used to reference application libraries in the weblogic-application.xml file, except that the <context-root> element is ignored.
At deployment time, the classpath of each referenced library is appended to the Web application’s classpath. Therefore, the search for all resources and classes occurs first in the original Web application and then in the referenced library.
The deployment tools, appc, wlcompile, and BuildXMLGen support libraries at the Web application level in the same way they support libraries at the application level. For more information about shared J2EE libraries and their deployment, see Creating Shared J2EE Libraries and Optional Packages in Developing Applications with WebLogic Server.
Three JSF (JavaServer™ Faces) and JSTL (JSP™ Standard Tag Library) packages are bundled with WebLogic Server as WebApp libraries. These libraries can be referenced by standard Web applications that use JSF or JSTL functionality.
For information on referencing these WebApp libraries with your Web applications, see Using WebApp Libraries With Web Applications in Developing Applications with WebLogic Server.
The following three packages are being made available as WebApp libraries in release 9.2:
The libraries are located in the WL_HOME/common/deployable-libraries directory. The JSF libraries include the JSTL JAR files for convenience, so that if an application references a JSF library, it automatically gets JSTL support as well.
The following tables list the JSF and JSTL library file names and their MANIFEST entries:
|