All Examples

Web Application (WAR) examples

This directory contains two simple examples Web Application for the WebLogic Server. Web Application are defined as part of the Servlet 2.2 specification. First, set up and run the cookie example to understand how a Web Application is deployed on the WebLogic Server. The next section describes how to create and deploy the cookie application as a WAR file. The security example illustrates how to use the Servlet2.2 security features of a Web Application.

setting up the cookie Web Application example

To setup and build the cookie Web Applicaiton example in this directory, follow these steps.

  1. Register the Web Application in the weblogic.properties file using the property: 
    weblogic.httpd.webApp.cookie=webapp_dir
    where cookie is part of the request URL that identifies the servlet context for this Web Application. HTTP requests made to this Web Application will follow the pattern: 
      http://myserver:myport/cookie/...
    And, webapp_dir is the full directory path to the root directory of the Web Application. The root directory of each Web Application is that Web Application's document root. The cookie Web Application example root directory is in this directory.

    To register the 'cookie' Web Application example, add the following line to your weblogic.properties file. Here we presume that you have installed WebLogic in the root directory /weblogic on your system for simplicity. You should alter the property appropriately. 

     weblogic.httpd.webApp.cookie=/weblogic/examples/webapp/cookie
    Here, we set the context path to "cookie". Note that the Web Application root directory and the context path need not have the same name.

  2. Next, compile the CookieCounter servlet in the Web Application. Server-side classes and servlets used by the Web Application should be located under the WEB-INF/classes directory. This is a different approach to the location used for servlets deployed on WebLogic prior to introduction of the Web Application. We refer to the older-style deployment as being deployed in the default servlet context.

    Open a new command shell, and set up your development environment, as described in the document Setting your development environment. Change to the WEB-INF directory under the cookie Web Application root directorty.

    If necessary, create a classes directory using: 

     $  mkdir classes

    Compile the CookieCounter servlet using the following command line: 

     $  javac -d classes CookieCounter.java

  3. Start (or restart) the WebLogic Server.

  4. Open a web browser and request the URL: 
      http://localhost:7001/cookie/

    The Web Application has been configured to serve the welcome page "hello.html" when the root directory is requested. You can see this configured in the WEB-INF/web.xml file shown below: 

      <welcome-file-list>
    <welcome-file>hello.html</welcome-file>
  </welcome-file-list>

    The CookieCounter servlet has been mapped to the URI path "monster". You can access it by requesting the URL: 

      http://localhost:7001/cookie/monster
    or clicking on the link in the welcome page.

    The Web Application has been configured to deliver an error JSP file if you attempt to request a bogus resource within this Web Application's servlet context. Try requesting the URL: 

     http://localhost:7001/cookie/bogus/file.html
    The default error page has been configured to handle HTTP 404 errors. You can configure other pages to handle other HTTP error codes.

how to create and deploy a WAR file

A WAR file is an archived web application. You can deploy a Web Application on the WebLogic Server in its archived format. This is useful for deploying an entire Web Application on a server other than the development environment host, a remote host, or for deploying to multiple servers in a cluster.

To create a WAR file open a command shell and change to the directory that contains the root directory of your Web Application. Set up your development environment as described in Setting your development environment, to ensure that you have a JDK in your environment path. Now, archive the entire Web Application using the JAR tool on the command line after the pattern: 

 $  jar cvf myWar.war myApp
where myWar.war is the name given to the newly created WAR file, and myApp is the root directory name of your Web Application.

Now move the .war file to the host server. We suggest that you place it in the myserver diectory in the WebLogic installation directory, but you can place it anywhere on a file system accessible by the host server.

Register the WAR file in the weblogic.properties file using the same property as for an un-archived Web Application: 

  weblogic.httpd.webApp.contextName=myWar.war
where contextName is the servlet context path that prepends request URIs to this Web Application. To archive and deploy the cookie example, change to the examples/webapp directory and create a WAR file using: 
 $  jar cvf cookieWar.war cookie
Move the cookieWar.war file to the myserver directory and register the WAR using following property in the weblogic.properties file: 
  weblogic.httpd.webApp.cookie=/weblogic/myserver/cookieWar.war
Now start (or restart) the WebLogic Server and request the URL http://localhost:7001/cookie

setting up the security example

To deploy the security Web Applicaiton example from this directory, follow these steps.

  1. Register the security Web Application in the weblogic.properties file using the property: 
    weblogic.httpd.webApp.mysite=webapp_dir
    where mysite is the context path and is the part of the request URL that identifies the servlet context for this Web Application. HTTP requests made to this Web Application will follow the pattern: 
      http://myserver:myport/mysite/...
    And, webapp_dir is the full directory path to the root directory of the Web Application. The root directory of each Web Application is that Web Application's document root. The security Web Application example root directory is this directory.

    To register the 'security' Web Application example, add the following line to your weblogic.properties file. Here we presume that you have installed WebLogic in the root directory /weblogic on your system for simplicity. You should alter the property appropriately. 

     weblogic.httpd.webApp.mysite=/weblogic/examples/webapp/security

  2. Add the following security realm properties to your weblogic.properties file. We shall use these user credentials to test the example. 
      weblogic.password.Bill=weblogic321
  weblogic.password.Ben=tengah321
  weblogic.security.group.admin=Bill

  3. Start (or restart) the WebLogic Server.

  4. Open a web browser and request the URL: 
      http://localhost:7001/mysite/

    The Web Application has been configured to serve the welcome page "welcome.jsp" when the root directory is requested. You can see this configured in the WEB-INF/web.xml file shown below: 

      <welcome-file-list>
      <welcome-file>welcome.jsp</welcome-file>
  </welcome-file-list>

  5. When you first visit any page in this Web Application, you are required to login, providing a username and password. This behavior is configured in the web.xml deployment descriptor with the following element. 
      <login-config>
      <auth-method>FORM</auth-method>
      <form-login-config>
          <form-login-page>/login.jsp</form-login-page>
          <form-error-page>/fail_login.html</form-error-page>
      </form-login-config>
  </login-config>
    Here, we configure the Web Application to use a FORM based login method. This is an alternative to BASIC authorization, where we can provide our own custom web page to prompt the user for login credentials using a simple HTML <form>. The login page is specified as login.jsp. This page must use a specific form, action, and field names, as defined by the Servlet2.2 specification. You can copy this simple form to create your own pages, and customize them to the same look and feel as your web site.

    The element <realm-name> is omitted here, so the default realm defined in the weblogic.properties file is used. We added two users 'Bill' and 'Ben' earlier.

  6. Enter username 'Ben' with password 'tengah321' and press submit. You should be logged in and see the welcome page. Click on the 'Configure background' link to attempt to access the edit.jsp page. You are denied access since you do not have 'admin' privileges.

    Access to all pages under the "/admin" directory is configured in the web.xml deployment descriptor using the following element: 

        <security-constraint>
        <web-resource-collection>
            <web-resource-name>AdminPages</web-resource-name>
            <description>
                These pages are only accessible by authorised administrators.
            </description>
            <url-pattern>/admin/*</url-pattern>
            <http-method>GET</http-method>
        </web-resource-collection>
        <auth-constraint>
            <description>
                These are the roles who have access
            </description>
            <role-name>
                admin
            </role-name>
        </auth-constraint>
        <user-data-constraint>
            <description>
                This is how the user data must be transmitted
            </description>
            <transport-guarantee>NONE</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

    This restricts access to these pages to anyone outside of the admin role, as defined in the WebLogic security realm.

  7. Now, click on the 'logout' link. This invokes the 'logout.jsp' page, which invalidates the current session. This effectively logs out the current user. On this page, you may revisit the Web Application, but you will need to log back in to gain access to any page.

    This time, login as 'Bill' with password 'weblogic321'. Bill belongs to the 'admin' group and should be able to access the 'Configure background' page.

there's more

Read more about Web Applciations in the Developers Guide, Writing a Web Application.

Other Developers Guides that describe the functionality used by this example are:

Copyright © 2000 BEA Systems, Inc. All rights reserved.

Last updated 01/10/2000