The main limitation that you need to be aware of when you are creating servlet beans is that open parameters are not executed precisely when their serviceParameter
is called. Instead, open parameters remain dormant until the servlet bean service
method completes and the dsp:droplet
tag begins reviewing the DropletActions
as described in the previous section. Code your servlet beans to expect that the servlet bean’s service
method is not immediately followed by the execution of the open parameters serviceParameter
.
The effects of this restriction have several side effects that might not be obvious, such as how nested open parameters interact with each other. See the following sections for details on these side effects.
Here are some general operations you should avoid:
Setting a global or thread-state variable that is accessed by code invoked from an open parameter.
Opening or closing a socket or JDBC result set that is accessed by code invoked from an open parameter.
Replacing the output stream/print writer in the response with your own designed to capture the output of an open parameter.
Open Parameter Dependencies
A servlet bean’s service
method cannot depend on the effects of a nested open parameter. Because the JSP executes the open parameter after the service
method completes, the service
method cannot act on any results or changes produced by the open parameter.
For example, when a certain output open parameter throws an exception, a service
method catches it and renders an error
open parameter. This sequence does not operate successfully because the service
method completes execution before the open parameter throws the exception.
A servlet bean’s service
method should not rely on values that are themselves determined during the execution of the open parameter. If an open parameter, for example, were to set the value of a profile attribute, you might think the service method can access that new value after the serviceParameter
method has returned. Because the open parameter changes the value after the service
method call completes, the service
method is unaware of the open parameter change.
Similarly, a servlet bean’s service
method cannot manipulate the output rendered from an open parameter. For example, the servlet bean’s service
method might attempt to translate the value produced from an open parameter into another language. Again, the servlet bean’s service
method is processed before the other open parameter delivers the value so the translation does not occur.
Actions that Rely on Timely Open Parameter Processing
A servlet bean cannot perform arbitrary actions around an open parameter and expect the open parameter to be affected by the results of those actions. For example, a servlet bean might:
set profile property to "x"
call open parameter "a"
set profile property to "y"
This code executes as follows:
Set profile property to
x
.Call open parameter
a
.Set profile property to
y
.Servlet bean code ends.
Execute open parameter
a
.
Because the open parameter is actually executed after the profile property is set to y
, the open parameter never sees the profile property set to x
.
Request parameters are an exception to this rule. When you set a request parameter on the Oracle Commerce Platform request object, that global parameter is visible to the open parameters within a given page. The record and play back mechanism in dsp:droplet
permits interdependence between open parameters and request parameters.