Assembling Your Web Application

 

On your e-business Web site, you use a Web application to implement your business model. It is one part (module) of an overall enterprise application that you assemble and deploy. (See Figure 4-1.)

With this modular approach, your development efforts focus on implementing your business model, and BEA provides the remaining infrastructure and tools for deploying and managing your Web application.

Figure 4-1 Your Web Application in Context

 

This topic describes how to assemble a Web application on a WebLogic Portal application server. It assumes that, at the very least, you have designed a prototype of your Web application and created skeletal JSPs. For more information about designing a prototype, refer to "Milestone 1" under "Workflow for Developing an E-Business Web Site" in the Strategies for Developing E-Business Web Sites.

This topic includes the following sections:

• Create and Populate a Directory Tree

• Create Deployment Descriptors

The next topic, Assembling and Deploying Enterprise Applications, describes how to deploy your Web application within an enterprise application.

 

---

Create and Populate a Directory Tree

You develop your Web application within a specified directory structure so that it can be archived and deployed on the application server. All servlets, classes, static files, and other resources belonging to a Web application are organized under a directory hierarchy. The root of this hierarchy defines the document root of your Web application. All files under this root directory can be served to the client, except for files under the special directory WEB-INF, located under the root directory. The name of the root directory is used to resolve requests for components of the Web application.

For more information about the directory structure of Web applications, refer to WebLogic Server Assembling and Configuring Web Applications guide.

For information specific to developing a WebLogic Portal Web application, refer to the following sections:

• Using a Reference Web Application as a Template

• Add JSP Tag Libraries to WEB-INF

Using a Reference Web Application as a Template

WebLogic Portal installs Web applications within the reference enterprise applications. If one of the samples approximates your business needs, you can duplicate and modify the sample. If you modify a sample Web application, make sure that you do the following before you deploy the Web application:

• Rename the root directory of your copy to reflect the purpose of your Web application.

• In the WEB-INF directory of your copy, remove any directories with names that start with _tmp. These directories contained compiled versions of JSPs that you have visited.

• In the root directory, index.jsp redirects requests to a Webflow for your Web application. The Webflow then determines which JSP (or portal) to display based on the Webflow properties that you create. The redirect statement follows this syntax:
  <jsp:forward page="/application?namespace=namespace_name">
  where namespace_name is the initial namespace for your Web application's Webflow.

  Change the namespace_name component of this statement to refer to the initial Webflow namespace of your Web application. For more information, refer to "Overview of Webflow" in the Guide to Managing Presentation and Business Logic: Using Webflow and Pipeline.

Add JSP Tag Libraries to WEB-INF

WebLogic Portal includes several JSP tag libraries which support the JSPs tags in your Web application. The tag libraries reside in JAR files that you must copy to your Web application. Each JAR file is named with the following convention: service_taglib.jar.

Copy each tag-library JAR file that your Web application uses to the WEB-INF/lib directory in your Web application. The reference copies are located in the following directories:

• PORTAL_HOME/lib/p13n/web

• PORTAL_HOME/lib/commerce/web

• PORTAL_HOME/lib/portal/web

• BEA_HOME/wlserver6.1/ext. The WebLogic Server tag libraries do not use the same naming convention as WebLogic Portal. In most cases, you need to copy only the weblogic-tags.jar file into your Web application.

For each tag library that you copy, you must also declare it in the Web application's web.xml file. For more information, refer to Taglib Declarations.

 

---

Create Deployment Descriptors

Each Web application uses two deployment descriptors: web.xml, which contains standard J2EE properties and weblogic.xml, which contains properties that are specific to WebLogic Portal.

To create deployment descriptors for your Web application, do the following:

• Copy Reference Files

• Review and Modify web.xml

• Modify weblogic.xml

The web.xml and weblogic.xml files contain properties that are scoped to a single Web application; they do not configure the parent enterprise application or any other modules in the enterprise application.

Figure 4-2 Scope of web.xml and weblogic.xml

 

Copy Reference Files

The reference deployment descriptors declare servlets, security roles and secured resources, JSP deployment options and other properties for a Web application.

To copy these files to your Web applications, do the following:

1. In the root directory of your Web application, create a directory named WEB-INF. For example:

   myWebApplication/WEB-INF

2. Find a reference Web application that approximates your business needs. Then copy its web.xml and weblogic.xml files to your WEB-INF directory. For example, to copy files from the wlcs Web application, copy the following files into your WEB-INF directory:

   PORTAL_HOME/applications/wlcsApp/wlcs/WEB-INF/web.xml
   PORTAL_HOME/applications/wlcsApp/wlcs/WEB-INF/weblogic.xml

Review and Modify web.xml

Open your web.xml file in a text editor to review its properties. You might need to modify some properties to support your environment.

Note: This document describes using a text editor to create and modify deployment descriptors. If you have deployed your Web application onto an active server, you can also use the WebLogic Server Administration Console to edit the deployment descriptors.

The elements in your web.xml file must appear in the following order:

• Display Name and Description

• Webflow Default Namespace

• URLs for the Webflow Service

• Listen Ports for Webflow-Generated URLs

• Declarations of Secure Links

• Filter Objects

• Listener Objects

• Servlet Registration and Mappings

• Session Configuration

• Welcome and Error Pages

• Taglib Declarations

• Name for commercePool Data Source

• Declarations of Secure JSPs

• Login Configuration

• Declaration of Security Roles

• EJB References

For a general description of properties in web.xml files, refer to "web.xml Deployment Descriptor Elements" in the WebLogic Server Assembling and Configuring Web Applications guide.

Display Name and Description

The <display-name> element determines the name that the WebLogic Server Administration Console uses for your Web application. Customers do not see this name.

The <description> element is optional. WebLogic Server Administration Console does not display the value of this element.

For more information, refer to "web.xml Deployment Descriptor Elements" in the WebLogic Server Assembling and Configuring Web Applications guide.

Webflow Default Namespace

Although you will generally have only one Webflow per Web application, namespaces can be used to separate a Webflow into a number of smaller, more manageable modules. Namespaces allow multiple developers to work with separate portions of a Webflow (and thus with separate configuration files and Pipeline Session properties) that feed into the larger Webflow for a Web application, without having to worry about naming collisions.

The following property declares the default namespace for the Web application:

<context-param>
<param-name>P13N_DEFAULT_NAMESPACE</param-name>
<param-value>namespace</param-value>
</context-param>

Make sure that the <param-value> matches the name of the Web application's default namespace. You use the E-Business Control Center to create Webflow namespaces. For more information, refer to "Webflow Components" in the Guide to Managing Presentation and Business Logic: Using Webflow and Pipeline.

URLs for the Webflow Service

Several elements in web.xml configure the URLs that Webflow generates:

• The following element determines the URL that Webflow uses to request the WebLogic Portal Administration Tools:

  <context-param>
  <param-name>WLCS_ADMIN_URL</param-name>
  <param-value>/tools/application/admin</param-value>
  </context-param>

  The wlcs sample application uses this element because it provides a link to the WebLogic Portal Administration Tools in the heading of its sample JSPs. In most environments, you do not need to include this element.

• The following element inserts /weblogic as a prefix for URLs that Webflow generates:

  <context-param>
  <param-name>P13N_URL_PREFIX</param-name>
  <param-value>/weblogic</param-value>
  </context-param>

  Include this element if you use a third party Web server (such as Apache) or other service in front of WebLogic Server and WebLogic Portal.

• The following element specifies a context for URLs that point to static resources that exist on a proxy server:

  <context-param>
  <param-name>P13N_STATIC_ROOT</param-name>
  <param-value></param-value>
  </context-param>

  Use this element in conjunction with the createStaticResourceURL() method to create links to static resources.

Listen Ports for Webflow-Generated URLs

The elements in this section enable Webflow to encode port numbers in URLs that are different from the port numbers that the WebLogic Server uses. For example, use these elements if you want Webflow-generated URLs to specify the port numbers of a proxy server.

<context-param>
<param-name>HTTP_PORT</param-name>
<param-value>port-number</param-value>
</context-param>

<context-param>
<param-name>HTTPS_PORT</param-name>
<param-value>port-number</param-value>
</context-param>

<context-param>
<param-name>P13N_URL_DOMAIN</param-name>
<param-value>host-name</param-value>
</context-param>

If you want the URLs in your Web application to use the same port numbers as the WebLogic Server instance, either deactivate these elements by surrounding them in comment tags,

<!-- -->, or change the values to match the listen port properties for the server.

Declarations of Secure Links

The following element syntax declares a set of files, pipelines, and input processors that need to be accessed via HTTPS. When the createWebflowURL() method encounters one of the resources you declare in the <param-value> subelement, it generates a URL that uses the HTTPS protocol.

<context-param>
   <param-name>HTTPS_URL_PATTERNS</param-name>
   <param-value>URLs-and-URL patterns</param-value>
</context-param>

You can add specific resource names or name patterns to the <param-value> element. All URLs-and-URL patterns must start with the name of a Webflow namespace. For example, the following line specifies that secureMain.jsp is a secured resource when called from the sampleapp_main Webflow namespace:
/sampleapp_main/secureMain.jsp

If you add any target names or patterns to the <param-value> element, you must also add them to the <security-constraint> element, which is described in Declarations of Secure JSPs.

Filter Objects

If you use the Event and Behavior Tracking services, include the following filter elements to forward ad clickthrough requests from Webflow to the Events Service:

<filter>
<filter-name>ClickThroughEventFilter </filter-name>

<filter-class>
com.bea.p13n.tracking.clickthrough.ClickThroughEventFilter
</filter-class>
</filter>

<filter-mapping>
<filter-name>ClickThroughEventFilter </filter-name>
<servlet-name>webflow</servlet-name>
</filter-mapping>

Listener Objects

If your application uses personalization or commerce services, you must register the AnonymousProfileListener, which listens for the creation of user sessions. When the server creates a user session, AnonymousProfileListener initializes the Anonymous user profile. Your application stores data in the Anonymous user profile until the customer logs in. If you want to maintain session information for anonymous customers, include the following elements in web.xml:

<listener>
<listener-class>
com.bea.p13n.servlets.AnonymousProfileListener
</listener-class>
</listener>

If you use the Event and Behavior Tracking services, include the following elements to notify the services of when the server begins and ends sessions:

<listener>
<listener-class>
com.bea.p13n.tracking.listeners.SessionEventListener
</listener-class>
</listener>

Servlet Registration and Mappings

The reference Web applications register the following servlets and define mappings between the servlet and a URL pattern:

• Servlets for Webflow Services

• Servlets for Personalization Services

• Servlets for Commerce Services

You can remove a declaration and mapping if your Web application does not use the servlet. If you create your own servlet to be used by this Web application, you must register it in the web.xml file. For information about the <servlet> and <servlet-mapping> elements, refer to "web.xml Deployment Descriptor Elements" in the WebLogic Server Assembling and Configuring Web Applications guide.

Place all servlet declarations in one group and all servlet mappings into a separate group. Place the declarations group immediately before the mappings group. (See Figure 4-3.)

Figure 4-3 Group Declarations and Mappings

 

Servlets for Webflow Services

Include the XML element from Table 4-1 to declare servlets and map URL patterns for Webflow services. Note that all <servlet> elements must be grouped together and all <servlet-mapping> must be grouped together. (See Figure 4-3.)

Table 4-1 Servlet Declarations for Webflow Services

Servlet	Declaration and Mapping
Webflow for Web applications that do not use portal services	<servlet> <servlet-name>webflow</servlet-name> <servlet-class> com.bea.p13n.appflow.webflow.servlets.internal.WebflowServlet </servlet-class> </servlet> ... <servlet-mapping> <servlet-name>webflow</servlet-name> <url-pattern>/application/*</url-pattern> </servlet-mapping>
Webflow for Web applications that use portal services	<servlet> <servlet-name>webflow</servlet-name> <servlet-class> com.bea.portal.appflow.servlets.internal.PortalWebflowServlet </servlet-class> </servlet> ... <servlet-mapping> <servlet-name>webflow</servlet-name> <url-pattern>/application/*</url-pattern> </servlet-mapping>

Servlets for Personalization Services

Include the XML elements from Table 4-2 to declare servlets and map URL patterns for personalization services. Note that all <servlet> elements must be grouped together and all <servlet-mapping> must be grouped together. (See Figure 4-3.)

Table 4-2 Servlet Declarations for Personalization Services

Servlet	Declaration and Mapping
ShowDocServlet Outputs the contents of a Document object. This servlet is useful when streaming the contents of an image that resides in a content management system. For more information, refer to "Creating and Managing Content" in the Guide to Building Personalized Applications.	<servlet> <servlet-class> com.bea.p13n.content.servlets.ShowDocServlet </servlet-class> <!-- Make showdoc always use the local ejb-ref DocumentManager --> <init-param> <param-name>contentHome</param-name> <param-value> java:comp/env/ejb/DocumentManager </param-value> </init-param> </servlet> ... <servlet-mapping> <servlet-name>ShowDocServlet</servlet-name> <url-pattern>/ShowDoc/*</url-pattern> </servlet-mapping>
clickThrough Redirects a user to an external site and fires a click event.	<servlet> <servlet-name>clickThroughServlet</servlet-name> <servlet-class> com.bea.p13n.tracking.clickthrough.ClickThroughServlet </servlet-class> </servlet> ... <servlet-mapping> <servlet-name>clickThroughServlet</servlet-name> <url-pattern>/clickThroughServlet/*</url-pattern> </servlet-mapping>
adClickThru Supports ad placeholders by recording click events and redirecting the browser to the ad's click-thru location. For more information, refer to "Working with Ad Placeholders" in the Guide to Building Personalized Applications.	<servlet> <servlet-name>adClickThru</servlet-name> <servlet-class> com.bea.p13n.ad.servlets.AdClickThruServlet </servlet-class> </servlet> ... <servlet-mapping> <servlet-name>adClickThru</servlet-name> <url-pattern>/AdClickThru/*</url-pattern> </servlet-mapping>

Servlets for Commerce Services

Include the XML elements from Table 4-3 to declare servlets for commerce services. You do not need to map these servlets to support WebLogic Portal services.

Table 4-3 Servlet Declarations for Commerce Services

Servlet	Declaration
Security Used only by site administrators to specify encryption values for securing credit card transactions.	<servlet> <servlet-name>Security</servlet-name> <servlet-class> com.beasys.commerce.ebusiness.security.EncryptionServlet </servlet-class> </servlet> <servlet> <servlet-name>KeyGenerator</servlet-name> <servlet-class> com.beasys.commerce.ebusiness.security.KeyGeneratorServlet </servlet-class> </servlet>

Session Configuration

The <session-config> element defines the session parameters for this Web Application. The WebLogic Portal sample applications use the <session-timeout> parameter to determine how many minutes of inactivity the server will tolerate before ending the session. Configure this to a suitable interval for your environment.

For more information, refer to "web.xml Deployment Descriptor Elements" in the WebLogic Server Assembling and Configuring Web Applications guide.

Welcome and Error Pages

The <welcome-file-list> element specifies a main page for your web application.

The <error-page> elements map error codes that the HTTP server returns to HTML files or JSPs.

For more information, refer to "web.xml Deployment Descriptor Elements" in the WebLogic Server Assembling and Configuring Web Applications guide.

Taglib Declarations

WebLogic Portal provides several libraries of JSP tags. You use the tags to implement WebLogic Portal features such as Webflow, Pipelines, and placeholders.

You declare each tag library that you use in your Web application. Use the following syntax to declare a tag library:

<taglib>
<taglib-uri>library.tld </taglib-uri>
<taglib-location>pname-to-JAR-file</taglib-location>
</taglib>

The pathname for the JAR file that contains the library is relative to the root of the Web application. For example,

<taglib>
<taglib-uri> weblogic.tld </taglib-uri>
<taglib-location>/WEB-INF/lib/weblogic-tags.jar
</taglib-location>
</taglib>

Name for commercePool Data Source

The following element declares a name for the commercePool data source:

<resource-ref>
<res-ref-name>jdbc/commercePool</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>CONTAINER</res-auth>
</resource-ref>

The weblogic.xml file maps the commercePool data source to a JNDI name, and the domain configures the data source. For information on the data source declaration in weblogic.xml, refer to Mapping of commercePool Data Source. For information on defining a data source for the domain, refer to Set Up JDBC Connection Pools and Data Sources.

Declarations of Secure JSPs

The <security-constraint> element declares a collection of resources (JSPs) that only specific roles can access. For more information, refer to "web.xml Deployment Descriptor Elements" in the WebLogic Server Assembling and Configuring Web Applications guide.

The example in Listing 4-1 is from the wlcs Web application. It secures all JSPs that are under the wlcs/user and wlcs/order directories and specifies that only users who are authenticated for CustomerRole can access those JSPs.

To give another role access to the resource collection in Listing 4-1, add a <role-name> element to the <auth-constraint> element. If you add a role name, you must add a declaration for the role name as described in Declaration of Security Roles.

To secure additional directories or specific files, add <url-pattern> elements. Note that a pattern or filename must start with a / character (forward slash). If you add any <url-pattern> elements, you must also add those patterns to the patterns defined for <param-name>HTTPS_URL_PATTERNS</param-name>. For more information, see Declarations of Secure Links.

Listing 4-1 Security Constraints

<security-constraint>
    <!-- Define a resource collection -->
    <web-resource-collection>
         <web-resource-name>Customer Profile - Self Administration Pages
         </web-resource-name>
         <description>Customer Profile - Self Administration Pages</description>

         <!-- URL pattern for the resource collection -->
         <url-pattern>/commerce/user/*</url-pattern>
         <url-pattern>/commerce/order/*</url-pattern>

         <http-method>GET</http-method>
         <http-method>POST</http-method>

    </web-resource-collection>

  <!-- This constraint applies to users with role "CustomerRole" -->

      <auth-constraint>
         <description>Users with role "CustomerRole"</description>
         <role-name>CustomerRole</role-name>
      </auth-constraint>

      <!-- For enabling SSL, specify CONFIDENTIAL or INTEGRAL. -->

      <user-data-constraint>
         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>

</security-constraint>

Login Configuration

The <login-config> element determines how users are authenticated. All of the WebLogic Portal sample applications use an HTML form (<auth-method>FORM</auth-method>) to authenticate users. If you use the FORM method, you can also use the P13NAuthFilter to initialize customer profiles when a customer logs on. For more information, refer to Customer Profile Initialization.

Declaration of Security Roles

You must include a <security-role> element to declare all of the roles that you use in the <security-constraint> (described in Declarations of Secure JSPs).

For example, the wlcs sample application gives CustomerRole access to secured JSPs (see Listing 4-1 above). Therefore, the wlcs web.xml file includes the following element:

<security-role>

<description>Registered customers with role CustomerRole
</description>
<role-name>CustomerRole</role-name>
</security-role>

In addition, the wlcs weblogic.xml file includes a <security-role-assignment> element, which maps the CustomerRole to a group name (principal) from the wlcsRealm. For more information about mapping security roles to principles, refer to Security-Role Mappings.

EJB References

The web.xml file must specify the home and remote interfaces for each EJB that the Web application uses. For example, the following XML element specifies interfaces for the AdService EJB:

<ejb-ref>
<description> The AdService for this webapp</description>
<ejb-ref-name>ejb/AdService</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.p13n.ad.AdServiceHome</home>
<remote>com.bea.p13n.ad.AdService</remote>
</ejb-ref>

For information on including these XML elements in your web.xml file, refer to Add JAR Files.

Modify weblogic.xml

In addition to the web.xml deployment descriptor, each WebLogic Portal Web application uses weblogic.xml to declare deployment properties that are specific to WebLogic Server.

After you copy a reference weblogic.xml to your Web application, review or modify the following properties:

• Security-Role Mappings

• Mapping of commercePool Data Source

• Check Authentication on JSP Forwarding

• JNDI Names for EJBs

• Cookies

• Support for Clusters

• JSP Deployment Options

• Customer Profile Initialization

For general information about weblogic.xml, refer to "weblogic.xml Deployment Descriptor Elements" in WebLogic Server Assembling and Configuring Web Applications.

Security-Role Mappings

Each Web application uses the following element syntax to map a J2EE security role to a user or group that a security realm uses to define ACLs:

<security-role-assignment>

<role-name>J2EE-role</role-name>

<principal-name>security-realm user or group</principal-name>

</security-role-assignment>

For example, WebLogic Portal uses the following element to map settings that its security realm defines for wlcs_customer to settings that application.xml defines for the CustomerRole J2EE security role:

<security-role-assignment>
<role-name>CustomerRole</role-name>
<principal-name>wlcs_customer</principal-name>
</security-role-assignment>

If you add groups to your security realm, you must add mappings to this section of weblogic.xml.

Mapping of commercePool Data Source

The following element maps the commercePool data source to a JNDI name:

<resource-description>
<res-ref-name>jdbc/commercePool</res-ref-name>
<jndi-name>weblogic.jdbc.jts.commercePool</jndi-name>
</resource-description>

The web.xml file declares a name for the commercePool data source, and the domain configures the data source. For information about the declaration in the web.xml file, refer to Name for commercePool Data Source. For information on defining a data source for the domain, refer to Set Up JDBC Connection Pools and Data Sources.

Check Authentication on JSP Forwarding

The following element requires authentication of any forwarded requests from a servlet or JSP:

<container-descriptor>
<check-auth-on-forward/>
</container-descriptor>

The Webflow service requires this element. For more information, refer to "weblogic.xml Deployment Descriptor Elements" in the WebLogic Server Assembling and Configuring Web Applications guide.

JNDI Names for EJBs

The weblogic.xml file must specify the JNDI names for each EJB that the Web application uses. Each declaration must be within the <reference-descriptor> element.

For example, the following XML subelement specifies the JNDI name for the AdService EJB:

<reference-descriptor>

<ejb-reference-description>
<ejb-ref-name>ejb/AdService</ejb-ref-name>
<jndi-name>
${APPNAME}.BEA_personalization.AdService
</jndi-name>
</ejb-reference-description>

... additional <ejb-reference-description> elements ...

</reference-descriptor>

For information on including these XML elements in your weblogic.xml file, refer to Add JAR Files.

Support for Clusters

If you deploy your Web application in a cluster, add the following elements to enable replication of HTTP Sessions across the cluster nodes:

<session-param>
  <param-name>PersistentStoreType</param-name>
  <param-value>replicated</param-value>
</session-param>

For information on other values for this element, refer to "weblogic.xml Deployment Descriptor Elements" in the WebLogic Server Assembling and Configuring Web Applications guide.

For more information about clustering, refer to the following:

• Deploying Clusters.

• Using WebLogic Server Clusters, which is part of the BEA WebLogic Server documentation set.

Cookies

WebLogic Server uses cookies for session management when supported by the client browser. The cookies that WebLogic Server uses to track sessions are set as transient by default and do not outlive the life of the browser.

By default, WebLogic Server assigns the same cookie name (JSESSIONID) to all Web applications on the current server instance. When you use any type of authentication, all Web applications that use the same cookie name use a single sign-on for authentication. Once a user is authenticated, that authentication is valid for requests to any Web application that uses the same cookie name. The user is not prompted again for authentication.

If you want to require separate authentication for a Web application, you can use the following element to specify a unique cookie name:

<session-descriptor>
<session-param>
<param-name>CookieName</param-name>
<param-value>
unique-cookie-name
</param-value>
</session-param>
</session-descriptor>

If your Web site supports Netscape 4.5 and higher, include the following element to set the cookie domain for the application.

<session-param>
<param-name>CookieDomain</param-name>
<param-value>.mycompany.com</param-value>
</session-param>

where .mycompany.com is your domain.

Note that all of the sample WebLogic Portal Web applications specify unique cookie names because they are not designed to be used in conjunction with other Web applications. You can design your WebLogic Portal Web application to be used with other Web applications and to support the WebLogic Server single sign-on feature.

For more information, refer to "Programming Tasks" in the WebLogic Server Programming WebLogic HTTP Servlets guide.

JSP Deployment Options

Each Web application includes a <jsp-descriptor> element to specify options for deploying JSPs.

For information about the <jsp-descriptor> element and its subelements, refer to "weblogic.xml Deployment Descriptor Elements" in the WebLogic Server Assembling and Configuring Web Applications guide.for more info go to WLS doc for this.

For recommended settings for some of the <jsp-descriptor> subelements, refer to the Performance Tuning Guide

Customer Profile Initialization

All WebLogic Portal Web applications must initialize customer profiles, especially if you want them to use campaigns, Behavior Tracking, and JSP tags that provide personalized content based on data in the customer's profile.

The P13NAuthFilter initializes customer profiles when a customer logs in using a form. If you want to use P13NAuthFilter, you must use the FORM authentication method. For information on configuring your application to use the FORM authentication method, refer to Welcome and Error Pages.

To use the P13NAuthFilter, add the following element to weblogic.xml:

<auth-filter>com.bea.p13n.servlets.P13NAuthFilter</auth-filter>

If you do not want to use P13NAuthFilter, you can initialize the customer profile with Webflow components or other methods. For more information, refer to "Setting Up JSP Tags and Scriptlets for Campaigns" in the Guide to Developing Campaign Infrastructure.