| Oracle® Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal 10g Release 3 (10.3.5) Part Number E14235-06 |
|
|
View PDF |
| Oracle® Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal 10g Release 3 (10.3.5) Part Number E14235-06 |
|
|
View PDF |
The Interceptor Framework is a consumer-side framework that lets you programmatically intercept and modify markup and user interaction-related WSRP messages sent to and received from producers. This framework exposes a set of interfaces that you can implement. These interfaces let you examine the content of a WSRP message and take specific action based on that content. For example, if a producer sends a registration error back to the consumer, an interceptor can detect that error and display an informative message to the user or, perhaps, automatically return the information required to complete the registration.
This chapter includes the following topics:
As Figure 9-1 illustrates, interceptors are implemented in the consumer. They intercept and allow processing of incoming and outgoing WSRP messages passed between the consumer and one or more producers. Interceptors are associated with specific consumer web applications (web application scoped). You can also group together several interceptors to accommodate more complex use cases.
Figure 9-1 Interceptors Run in Consumer Applications
The interceptor framework defines five public interceptor interfaces. To work with interceptors, you implement one or more of these interfaces and register your implementation classes in a configuration file called wsrp-consumer-handler-config.xml. This configuration file is web application-scoped, and resides in the consumer web application's WEB-INF directory. See Section 9.6, "Configuring Interceptors" for more information on the configuration file.
To work with interceptors effectively, you must be familiar with basic WSRP operations, such as getMarkup and performBlockingInteraction. You need to understand the purpose of these operations and how they fit into the life cycle of proxy portlets. See Section 9.4, "Designing Interceptors".
The rest of this chapter explains how to use these interfaces and includes detailed examples and use cases.
If you are a consumer-side developer, you can use the Interceptor Framework for many different purposes. Some of the most common use cases for interceptors include:
Handling Errors – You can use interceptors to handle errors returned from a producer. For instance, if a specific producer is not registered, you can trap the registration error and handle it as you wish. You may display an informative message to the user, or you may choose to automatically register the producer. An interceptor can also catch an I/O exception, which can occur if the producer is unavailable. In this case, you might choose to handle the error by displaying an informative message for the user, prevent future requests to the producer, or chose to redirect to another producer.
Caching Markup – You can implement an interceptor to cache markup returned from a producer. This feature allows you to use any external caching system you choose. In addition, by caching markup on the consumer, you can, in some circumstances, reduce round-trip communication between the consumer and producer.
Validating Data – You can use interceptors to filter user submitted data. If you detect the user's data is invalid, you can display an informational message, or you can prevent the data from being sent to the producer.
Replacing Markup – An interceptor can filter, replace, modify markup data sent from the producer. An interceptor can also modify the navigational state of a remote portlet. For information on navigational state, see Section 3.5, "Life Cycle of a Remote Portlet".
Modifying HTTP Headers – Interceptors can add or remove some kinds of HTTP headers, and can also inspect response headers. Refer to Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal for details on which kinds of HTTP headers can be modified by Interceptors.
This section lists the basic steps involved in creating an interceptor. More detailed information on each step is available in the other sections of this chapter. The basic steps include:
Determine the purpose of your interceptors. When you know the work you want to accomplish with interceptors, you can then decide which of the interfaces to implement. For more information, see Section 9.4, "Designing Interceptors".
Configure the interceptors. After you know the names of your interceptor classes, you need to specify the interceptor classes in a configuration file. See Section 9.6, "Configuring Interceptors" for detailed information.
Implement the interceptor interface(s). The interceptor interfaces are discussed in Section 9.5, "Interceptor Interfaces". For more detailed information on the interceptor interfaces, you can refer to Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal.
Test the interceptors.
When designing interceptors, you must first decide what kind of work you want to perform. Depending on the task, you can implement one or more of the interfaces. Each interface is designed to handle a particular type of WSRP operation. For instance, if you are interested in intercepting form data before it is sent to a producer, you might choose to implement the IBlockingInteractionInterceptor. If you are handling registration faults, then you might implement all of the interfaces.
Interceptors are designed to handle the following types of WSRP operations. These operations are wrapped in SOAP messages that are passed between consumers and producers using WSRP:
initCookie and initCookieResponse
getMarkup and getMarkupResponse
performBlockingInteraction and performBlockingInteractionResponse
handleEvents and handleEventsResponse
getRenderDependencies and setRenderDependencies
To use interceptors effectively, you need to be familiar with the purpose of these operations and how they relate to the life cycle of a proxy portlet. For instance, performBlockingInteraction requests are sent when a user submits form data in a portlet.
Tip:
If you are interested in learning more about WSRP and the preceding types of WSRP operations, see Inside WSRP at http://www.oracle.com/technology/pub/articles/dev2arch/2005/03/inside_wsrp.html. For a more general overview, see Chapter 3, "Federated Portal Architecture."
When designing interceptors, also think about the number of interceptors you need to accomplish your work. You can associate more than one interceptor with a producer by creating a group of interceptors. A group is subject to specific rules that govern the order in which methods are executed. For more information see Section 9.7, "Order of Method Execution".
Tip:
Because every request might not have the same data available, it is important to add proper null-condition checks and take appropriate action if data is missing.
This section describes the five public interceptor interfaces, their methods, method return values, and the context objects that are accessible to the interface methods. This section includes these topics:
The interceptor methods receive context objects that you can use to get and set values in the intercepted SOAP messages. The context object created for each type of interceptor varies depending on the WSRP operation it represents. For instance, the initCookie context object does not contain the same information as the context object for the handleEvents operation. For detailed information on these objects, refer to Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal for the interceptor interfaces. This section describes the flow in which request and response context objects are created and used by interceptors.
Before a message is sent to a producer, or after it is received, the interceptor framework creates an appropriate context object that is passed to the interceptor methods. This object wraps certain elements related to the message. Using methods of the context object, the interceptor can retrieve and set these elements. For example, when a user clicks a link in a remote portlet, the interceptor framework creates a request context object which it then passes to the preInvoke() method of the interceptors. After passing through the interceptors and possibly being modified, the request object is used to construct a message that is sent to the producer. Likewise, the interceptor framework constructs a response context object from an incoming message and passes the object the appropriate interceptor methods.
As illustrated in Figure 9-2, a request context is passed from the proxy portlet to the preInvoke() methods of registered interceptors. The request context contains information related to the portlet. After processing by one or more interceptors, the interceptor framework creates a message. This message includes any modifications made by the preInvoke() method.
Figure 9-2 Handling a Request Context Object
Similarly, as shown in Figure 9-3, the response context object created from an incoming message is passed to the postInvoke() method of the interceptors that are associated with the producer that generated the response.
Figure 9-3 Handling a Response Context Object
Finally, as shown in Figure 9-4, the response context object created from an incoming error or fault message is passed to either the onFault() or onIOFailure() method. Note that in the case of an onIOFailure, a response SOAP message might not be generated.
The five public interceptor interfaces are summarized in Table 9-2. These interfaces are in the com.bea.wsrp.consumer.interceptor package. See Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal for information on these interfaces.
Table 9-1 Interceptor Interfaces
| Interface | Description |
|---|---|
|
IGetMarkupInterceptor |
Allows you to intercept and modify a message that is being sent in a |
|
IInitCookieInterceptor |
Allows you to intercept the |
|
IBlockingInteractionInterceptor |
Allows you to intercept and modify a |
|
IHandleEventsInterceptor |
Allows you to intercept a |
|
IGetRenderDependenciesInterceptor |
Allows you to intercept a |
|
IGetResourceInterceptor |
Allows the consumer to intercept a |
|
IResourceServletInterceptor |
Allows you to intercept requests and responses to the resource proxy servlet. The preInvoke and postInvoke parameters (see Section 9.5.3, "Interface Methods") are configured in the web.xml as a servlet init-param named For more information, see Section 9.9, "Using Resource Proxy Interceptors." |
Each interceptor interface includes the same four methods. Table 9-2 summarizes the interceptor methods and when each method is called. Possible return values for each method are discussed in Section 9.5.4, "Interceptor Method Return Values".
Tip:
The following table is a general summary only, and does not include method parameters or return values. The specific method signatures depend on the interface in which the method is used. Refer to the Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal for a detailed description of each method and its parameters.
Table 9-2 Interceptor Methods
| Method | Description |
|---|---|
preInvoke() |
This method is called before creating a SOAP message to send to the producer. For example, this method is called after a user clicks on a link in a proxy portlet. One use of this method is to intercept a user's input data to verify that it is complete. |
postInvoke() |
This method is called after a producer has processed its request and sent a response back to the consumer. This method can be used to intercept and filter the markup returned by the producer. |
onFault() |
This method is called when the producer returns a fault. This method can be used to examine the error and display an informational message or take another appropriate action. |
onIOFailure() |
This method is called when the there is an IOException while sending or receiving a message. This method can be used to display an informational message or take another appropriate action. |
The following tables list the possible return values for each of the four interceptor methods:
For more information on return values, see Section 9.7.3, "How Return Status Affects Execution Order".
Table 9-3 Return Values for preInvoke()
| Return Value | Description |
|---|---|
Status.PreInvoke.CONTINUE_CHAIN |
Indicates normal execution. |
Status.PreInvoke.ABORT_CHAIN |
Skips calling |
Status.PreInvoke.SKIP_REQUEST_ABORT_CHAIN |
Skips calling |
Table 9-4 Return Values for postInvoke()
| Return Value | Description |
|---|---|
Status.PostInvoke.CONTINUE_CHAIN |
Indicates normal execution. |
Status.PostInvoke.ABORT_CHAIN |
Skips calling |
Table 9-5 Return Values for onFault()
| Return Value | Description |
|---|---|
Status.OnFault.CONTINUE_CHAIN |
Indicates normal execution. The consumer will handle the fault if rest of the interceptors also return |
Status.OnFault.ABORT_CHAIN |
Skips calling |
Status.OnFault.RETRY |
Re-sends the message that caused the fault. The |
Status.OnFault.HANDLED |
Skips calling |
Table 9-6 Return Values for OnIOFailure()
| Return Value | Description |
|---|---|
Status.OnIOFailure.CONTINUE_CHAIN |
Indicates normal execution. The consumer will handle the IO failure if the rest of the interceptors also return |
Status.OnIOFailure.ABORT_CHAIN |
Skips calling |
Status.OnIOFailure.RETRY |
Re-sends the message that caused the IO failure. The |
Status.OnIOFailure.HANDLED |
Skips calling |
The interceptors are configured in wsrp-consumer-handler-config.xml, a web application scoped configuration file. This configuration file requires two entries: interceptor and interceptor-group. Both of these entries must be present in the configuration file.
Tip:
You'll find the wsrp-consumer-handler-config.xml file in the Eclipse Project Explorer view under Merged Project Content/WEB-INF. To edit this file, right-click it and select Copy to Project. Then, open the file in the editor.
The <interceptor> element specifies the fully qualified interceptor class name and provides an arbitrary, unique name. The interceptor class must also be in the web application's class path or another accessible class path, such as a system-defined class path. Each interceptor specified by an <interceptor> element must be referenced in a group, therefore, you must configure at least one <interceptor-group>.
The <interceptor> element includes the following elements.
name – A unique name within the scope of a web application.
producer-handle – (Optional) If you specify the handle for a registered producer, the intereceptor(s) in the group will only be called on messages received from or sent to that producer. If you do not specify a producer handle, then the interceptor(s) in the group will be called for all producers associated with the consumer.
interceptor-name – The name(s) of the interceptors you want to include in the group. Use the name(s) specified in the interceptor element(s).
The <interceptor-group> element includes the following elements.
name – A unique name within the scope of a web application.
producer-handle – (Optional) If you specify the handle for a registered producer, the intereceptor(s) in the group will only be called on messages received from or sent to that producer. If you do not specify a producer handle, then the interceptor(s) in the group will be called for all producers associated with the consumer.
interceptor-name – The name(s) of the interceptors you want to include in the group. Use the name(s) specified in the interceptor element(s).
For more information on groups, and the order in which methods in groups are called, see Section 9.7, "Order of Method Execution".
Example 9-1 shows a simple configuration, including two interceptors and one group.
Example 9-1 Sample Configuration File
<?xml version="1.0" encoding="UTF-8"?>
<wsrp-consumer-handler-config ...>
<interceptor>
<name>AutoRegisteringInterceptor</name>
<class-name>myInterceptors.AutoRegistrationInterceptor</class-name>
</interceptor>
<interceptor>
<name>ErrorMessageCustomizer</name>
<class-name>myInterceptors.ErrorMessageCustomizer</class-name>
</interceptor>
<interceptor-group>
<name>Group_1</name>
<producer-handle>MyProducer</producer-handle>
<interceptor-name>AutoRegistrationInterceptor</interceptor-name>
<interceptor-name>ErrorMessageCustomizer</interceptor-name>
</interceptor-group>
</wsrp-consumer-handler-config>
This section discusses the factors that affect the order of method execution in interceptors and groups of interceptors.
An interceptor group is a collection of interceptors whose methods are called in a well-defined order. A group can be associated with a specific producer or not associated with any producer. If associated with a single producer, then the interceptors in the group will be called only when requests and responses occur between the consumer and that specific producer. If no producer is associated with a group, then the group's interceptors are called when communication occurs between the consumer and all producers associated with it. For detailed information on configuring a group, see Section 9.6, "Configuring Interceptors".
This section describes the order in which interceptor methods are called if all methods return a status value of CONTINUE_CHAIN.
Recall that all interceptors contain four methods: preInvoke(), postInvoke(), onFault(), and onIOFailure(). In an interceptor chain, all of the preInvoke() methods are executed, then the postInvoke() methods, the onFault() methods, and finally the onIOFailure() methods.
Figure 9-5 illustrates the order in which methods in an interceptor chain are called for the following chain definition:
Example 9-2 Example Interceptor Chain Definition
<interceptor-chain>
<name>Chain-A</name>
<producer-handle>myProducer</producer-handle>
<interceptor-name>Interceptor2</interceptor-name>
<interceptor-name>Interceptor3</interceptor-name>
<interceptor-name>Interceptor3</interceptor-name>
<interceptor-name>Interceptor4</interceptor-name>
</interceptor-chain>
The illustration assumes that all methods return the CONTINUE_CHAIN status. Note that all of the preInvoke() methods are called first in the order in which the interceptors appear in the chain configuration, then the postInvoke() methods are called in the reverse order. After all the postInvoke() methods are called, the onFault() methods are called in the order shown in Figure 9-5. Finally, the onIOFailure() methods are called in the order shown in Figure 9-5. If onFault() or onIOFailure() are called, then postInvoke() is not called.
Figure 9-5 Default Method Order in Interceptor Chains
Tip:
Be aware that you can define interceptors in the configuration file that are associated with specific producers or not associated with any specific producer. An unassociated interceptor does not have a <producer-handle> element defined with it. Unassociated interceptors are always called first for all producer transactions, before the interceptors that are associated with a specific producer are called. Unassociated interceptors are called in the order in which they appear in the configuration file. See Section 9.6, "Configuring Interceptors" for more information.
The return status of interceptor methods also affects the order in which interceptor methods are executed. It's helpful to think of chains of interceptor methods. It's easier to understand the way interceptor chains work if you think of four separate chains: a preInvoke() chain, a postInvoke() chain, an onFault() chain, and an onIOFailure() chain. If you think of chains this way, it's easier to understand the effect of return status on the execution of the chain.
Table 9-2 summarizes the possible return values for interceptor methods and how they affect the order of execution in a chain.
Table 9-7 Interceptor Method Return Values
| Return Value | Description |
|---|---|
CONTINUE_CHAIN |
If all methods return a |
ABORT_CHAIN |
Skips calling methods of the subsequent interceptors in the chain, but sends the message on to the producer. A use case for |
SKIP_REQUEST_ABORT_CHAIN |
Skips calling methods of the subsequent interceptors in the chain and skips sending the request message to the producer. A use case for |
HANDLED |
Skips calling the fault-handling methods of the subsequent interceptors in the chain and assumes that fault has been consumed by the interceptor. The interceptor is responsible for providing markup data inputstream, in the absence of it will result in rendering "no markup found error" error message in the portlet. |
RETRY |
Re-sends the message that caused the fault. The fault-handling methods of the subsequent interceptors in the chain are not called. Only one retry is permitted per message. |
Note:
If ABORT_CHAIN or SKIP_REQUEST_ABORT_CHAIN is returned from preInvoke(), all of the interceptors will still be called, in reverse order, during the postInvoke() phase.
A new instance of an interceptor implementation class is created for every message before calling preInvoke(). This same instance is reused to call postInvoke(), onFault(), and onIOFailure(). This allows you to set and use instance variables within the scope of a request. For a given instance, all methods are called once; however, preInvoke() and postInvoke() can be called one more time if the RETRY status is returned by either onFault() or onIOFailure(). Only one retry is permitted per message.
This section includes several examples that illustrate the flow of method execution in an interceptor chain. Refer to Table 9-2 for details on interceptor return values referred to in these examples.
Figure 9-6 illustrates the flow in an interceptor chain when the preInvoke() method is called on the chain. When a status of ABORT_CHAIN returned, a message is immediately returned to the producer. The preInvoke() methods of subsequent interceptors in the chain are not called.
Figure 9-6 preInvoke() Chain with ABORT_CHAIN Return Value
Figure 9-7 illustrates another example of the flow in an interceptor chain when the preInvoke() method is called on the chain. When a status of SKIP_REQUEST_ABORT_CHAIN is returned, no message is sent to the producer. The preInvoke() methods of subsequent interceptors in the chain are not called.
Figure 9-8 illustrates the flow in an interceptor chain when the onFault() method is called on the chain. When a status of RETRY is returned, the same message that caused the failure, with possible modifications inserted by the interceptor, is returned to the producer. The onFault() methods of subsequent interceptors in the chain are not called. Only one retry is permitted. If the same fault is returned, the interceptor framework assumes that the error is handled by the interceptor, and a status of HANDLED is returned.
Figure 9-8 onFault() Chain with RETRY Return Value
Figure 9-9 illustrates the flow in an interceptor chain when the onIOFailure() method is called on the chain. In this case, the no message is returned to the producer, and the framework assumes that fault has been consumed by the interceptor. The onIOFailure() methods of subsequent interceptors in the chain are not called. Only one retry is permitted. The second retry is not honored, and the fault or exception is passed to a proxy portlet. If the same fault is returned, the interceptor framework assumes that the error is handled by the interceptor, and a status of HANDLED is returned.
Figure 9-9 onIOFailure() Chain with HANDLED Return Value
This section illustrates two simple interceptor implementations. The first implements the onFault() method and modifies the error message that is returned to the producer. The second implements onFault() and redirects portlet to display an error page.
This section includes these sections:
You can use interceptors to retrieve and modify exceptions thrown from the producer. In Example 9-3, the onFault() method retrieves a Throwable from the response. You can design an onFault() method to examine the exception and take any appropriate action. In this case, the error message is retrieved, modified, and written back to the IGetMarkupResponseContext object. The return status HANDLED has the following effects:
If the interceptor is part of a chain, it skips calling subsequent onFault() methods in the chain.
Returns markup data to the producer. This markup is then displayed in the portlet. If you do not return markup data to the producer, the portlet displays the message "No Markup Found Error."
Example 9-3 ErrorMessageCustomizer
import com.bea.wsrp.consumer.interceptor.IGetMarkupInterceptor;
import com.bea.wsrp.model.markup.IGetMarkupRequestContext;
import com.bea.wsrp.model.markup.IGetMarkupResponseContext;
import com.bea.wsrp.consumer.interceptor.Status;
import weblogic.xml.util.StringInputStream;
public class ErrorMessageCustomizer implements IGetMarkupInterceptor
{
public Status.PreInvoke preInvoke(IGetMarkupRequestContext requestContext)
{
return Status.PreInvoke.CONTINUE_CHAIN;
}
public Status.PostInvoke postInvoke(IGetMarkupRequestContext requestContext,
IGetMarkupResponseContext responseContext)
{
return Status.PostInvoke.CONTINUE_CHAIN;
}
public Status.OnFault onFault(IGetMarkupRequestContext requestContext,
IGetMarkupResponseContext responseContext,
Throwable t)
{
String message = "This Message is Customized by ErrorMessageCustomizer\n";
message = message + t.getMessage();
StringInputStream stringInputStream = new StringInputStream(message);
responseContext.setMarkupData(stringInputStream);
return Status.OnFault.HANDLED;
}
public Status.OnIOFailure onIOFailure(IGetMarkupRequestContext requestContext,
IGetMarkupResponseContext responseContext, Throwable t)
{
return Status.OnIOFailure.CONTINUE_CHAIN;
}
}
In this example, the onFault() method is implemented to include an error JSP page in the portlet.
Example 9-4 DisplayErrorPage Class
import com.bea.wsrp.consumer.interceptor.IGetMarkupInterceptor;
import com.bea.wsrp.model.markup.IGetMarkupRequestContext;
import com.bea.wsrp.model.markup.IGetMarkupResponseContext;
import com.bea.wsrp.consumer.interceptor.Status;
import weblogic.xml.util.StringInputStream;
import myClasses.MyError;
public class DisplayErrorPage implements IGetMarkupInterceptor
{
public Status.PreInvoke preInvoke(IGetMarkupRequestContext requestContext)
{
return Status.PreInvoke.CONTINUE_CHAIN;
}
public Status.PostInvoke postInvoke(IGetMarkupRequestContext
requestContext, IGetMarkupResponseContext responseContext)
{
return Status.PostInvoke.CONTINUE_CHAIN;
}
public Status.OnFault onFault(IGetMarkupRequestContext requestContext,
IGetMarkupResponseContext responseContext,
Throwable t)
{
try
{
if (t instanceof MyError) {
responseContext.render(requestContext.getHttpServletRequest(),
requestContext.getHttpServletResponse(),
"/redirectTarget/myTarget.jsp");
} else {
responseContext.render(requestContext.getHttpServletRequest(),
requestContext.getHttpServletResponse(),
"/redirectTarget/defaultTarget.jsp");
}
}
catch (ServletException e)
{
e.printStackTrace();
}
catch (IOException e)
{
e.printStackTrace();
}
return Status.OnFault.HANDLED;
}
public Status.OnIOFailure onIOFailure(IGetMarkupRequestContext
requestContext, IGetMarkupResponseContext
responseContext, Throwable t)
{
return Status.OnIOFailure.CONTINUE_CHAIN;
}
}
This section explains how to use the WSRPResourceServletInterceptor and ClipperResourceServletInterceptor.
WLP employs a ResourceProxyServlet to proxy resource requests from the consumer portal to the producer. This servlet makes it possible for a consumer to request resources, like images, from a producer (which may be behind a firewall and otherwise unavailable to the consumer). The producer maps resource requests (URLs) to the ResourceProxyServlet on the consumer. When a browser tries to resolve a resource, it makes the request to ResourceProxyServlet on the consumer, which then requests the resource from the producer. By default, ResourceProxyServlet is added to a WLP application's web.xml file.
The IResourceServletInterceptor intercepts requests and responses from the ResourceProxyServlet. This interceptor can be used for:
Setting up a 2-way SSL
Setting up an HTTP or SOCKS proxy
Modifying the target URL
Adding or removing headers (on both requests and responses)
Rewriting markup
The IResourceServletInterceptor is used by both WSRP (for proxied and served resources) and the WLP Web Clipper Portlet. Default implementations are provided with WLP for both of these cases.
IResourceServletInterceptor follows the same programming model as the other WSRP interceptors described in this chapter. Like the other interceptors, IResourceServletInterceptor includes preInvoke() and postInvoke() methods. The major difference is that resource proxy interceptors are configured as a servlet init-param in the web.xml file. This servlet init-param is called resource-servlet-interceptors.
Unlike the other interceptors, the preInvoke and postInvoke parameters are configured in the web application's web.xml file. To configure these parameters, use a servlet init-param named resource-servlet-interceptors. Add the parameter values using a pipe (|) to separate the list of interceptor classes. The classes must implement com.bea.wsrp.consumer. resource.IResourceServletInterceptor.
Example 9-5 illustrates a resource-servlet-interceptor parameter for a WSRP resource proxy. Example 9-6 illustrates a resource-servlet-interceptor parameter for a Web Clipper Portlet resource proxy.
Example 9-5 Configuring a WSRP Resource Proxy in web.xml
<servlet>
<servlet-name>com.bea.wsrp.consumer.resource.ResourceProxyServlet</servlet-name>
<servlet-class>com.bea.wsrp.consumer.resource.ResourceProxyServlet</servlet-class>
<init-param>
<param-name>resource-servlet-interceptors</param-name>
<param-value>com.bea.wsrp.consumer.resource.WsrpResourceServletInterceptor|
com.bea.wsrp.qa.TestInterceptor</param-value>
</init-param>
</servlet>
Example 9-6 Configuring a Clipper Portlet Resource Proxy in web.xml
<servlet>
<servlet-name>com.bea.netuix.clipper.ClipperResourceProxyServlet</servlet-name>
<servlet-class>com.bea.netuix.clipper.ClipperResourceProxyServlet</servlet-class>
<init-param>
<param-name>resource-servlet-interceptors</param-name>
<param-value>com.bea.netuix.clipper.ClipperResourceServletInterceptor|
com.bea.netuix.clipper.qa.TestInterceptor</param-value>
</init-param>
</servlet>
If not otherwise configured, both WSRP and Web Clipper Portlets use a default interceptor. The defaults perform most of the basic functions required by the resource proxy servlet.
Caution:
Oracle does not recommend that the default resource proxy interceptors be replaced. Instead, add additional interceptors before or after the default interceptor. See Example 9-5 and Example 9-6. You can also extend (subclass) the interceptor.
Some functions performed by the default interceptors include:
Setting up the request and response contexts:
Parsing the URL
Transferring headers
Rewriting the response markup
Performing security checks
Adding the appropriate cookies.
Because the default interceptors perform these functions, Oracle recommends that custom interceptors operating on the request (preInvoke) be placed after the base interceptor, and interceptors operating on the response should be placed before the base interceptor. If using the approach of extending the base interceptor, call the super method on any overridden method, as shown in Example 9-7.
Example 9-7 Overriding Base interceptor Methods
public class MyInterceptor extends WsrpResourceServletInterceptor {
@Override
protected PreInvoke preInvoke(IResourceServletRequestContext requestContext) throws IOException {
PreInvoke superPreInvoke = super.preInvoke(requestContext);
if (superPreInvoke == PreInvoke.CONTINUE_CHAIN) {
final HttpURLConnection connection = requestContext.getURLConnection;
connection.addRequestProperty("X-MY-SECURITY-TOKEN", generateSecurityToken());
}
return superPreInvoke;
}
}
|
 Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|