Previous Next vertical dots separating previous/next from contents/index/pdf

Upgrading Page Flows

This topic gives more detail about upgrade changes noted for page flows.

For a more complete list of changes affecting applications upgraded from version 8.1, see Changes During Upgrade from WebLogic Workshop 8.1 to Version 10.0.

Changes When Upgrading from Version 8.1 NetUI JSP Tags to Beehive NetUI JSP Tags

When upgrading using upgrade tools, you'll have the option to choose to replace your version 8.1 NetUI JSP tags with the Beehive NetUI JSP tags, which provide enhanced functionality over the version 8.1 tags. (The Beehive tags are the default for new web projects in Workshop for WebLogic version 10.0.) The default behavior is not to replace version 8.1 tags with Beehive tags. Instead, by default version 8.1 tags are upgraded to a version of the 8.1 tags that is compatible with a version 9.x server.

Note: A JSP page can use a combination of compatible 8.1 tags and Beehive tags. However, this is only supported when the combination is due to an upgrade outcome in which some version 8.1 tags have no Beehive counterparts.

As you might imagine, the decision you make about the tags will have a broad impact on the JSP portion of your application. Before choosing, consider the following:

Tag Changes

If you choose to replace version 8.1 tags with Beehive tags during application upgrade, many of the version 8.1 tags will be replaced with easily identifiable Beehive counterparts. There will be exceptions to this predictability, as the following table describes.

Version 8.1 Tag Version 10.0 Tag
tree None; deprecated
grid None; deprecated
label span
choice None; deprecated
choiceMethod None; deprecated
repeater repeater
content None; deprecated
callControl None; deprecated
declareControl None; deprecated
visible None; deprecated
getNetuiTagName None; deprecated
anchor anchor
(Not migrated if the forward attribute is set.)
imageAnchor imageAnchor
(Not migrated if the forward attribute is set.)

Attribute Changes

During upgrade some JSP tag attributes may be migrated to new attributes, or simply removed. The following table describes possible changes.

Version 8.1 Tag Attribute Action
Removed if a tagId attribute is present; otherwise migrated to tagId.
anchor forward
Tag is not migrated if this attribute is present.
anchor page
Removed if an href attribute is present; otherwise migrated to href by removing the initial '/'
bindingUpdateErrors id Removed
form id Removed if a tagId attribute is present; otherwise migrated to tagId
form name
Change to beanName
form type
Change to beanType
form scope
Change to beanScope
Removed; netui:attribute tag added as a child of the image tag, for example:
    <netui:attribute name="lowsrc" value="blurryFoo.gif"/>
Removed if a src attribute is present, otherwise migrate to src by removing the initial '/'
Removed if a tagId attribute is present, otherwise migrate to tagId
lowsrc attribute and netui:attribute tag added as a child of the image tag, for example:
    <netui:attribute name="lowsrc" value="blurryFoo.gif"/>
imageAnchor scope
imageAnchor forward
Tag not migrated if this attribute is present.
imageAnchor page
Removed if an href attribute is present; otherwise migrated to href by removing the initial '/'
imageButton height
imageButton width
imageButton hspace
imageButton vspace
imageButton id
Removed if a tagId attribute is present; otherwise migrated to tagId
imageButton page
Removed if a src attribute is present; otherwise migrated to src
Removed if a tagId attribute is present; otherwise migrated to tagId
label tabIndex Removed
radioButtonGroup tagId
select onSelect Removed
select nullableTop Removed
Removed if a tagId attribute is present; otherwise migrated to tagId
Changed to idScope
Changed to idScope
Changed to key
Name migrated to "bundleName"
Name migrated to "bundleName"
template:section visibility If the visibility attribute is present and it has a value, the value is migrated to the visible attribute; otherwise if the visibility attribute is not present, the visible attribute is migrated.

Upgrade Sets the Default Expression Language to a Backward-Compatible Version

When upgrading an application, you'll be prompted to upgrade version 8.1 NetUI JSP tags to Beehive NetUI JSP tags. Whether or not you choose to upgrade to Beehive, the default expression language in your upgraded application will be a backward-compatible version, rather than the version used for new applications. This is because the backward-compatible version is more permissive, allowing you to continue with your existing code until you are ready to upgrade fully. If and when you choose to upgrade fully to the Beehive JSP tag technologies, you should change the default expression language to the version that supports Beehive tags.

If you add Beehive JSP tags to your pages, they will use the Beehive version of the expression language. Until that time, you should continue to use the backward-compatible expression language as the default. See Changing the Default Expression Language Used by JSP Tags for more information.

Note: In general, you should regard the version 8.1 NetUI tags as deprecated; new code should use the Beehive NetUI JSP tags.

Changing the Default Expression Language Used by JSP Tags

When you have fully upgraded your JSP pages so that they use the Beehive JSP tags, you should change the default expression language from the backward-compatible version to the version 10.0.

Note: Before making this change, you should be aware of code changes that might be required.

You can change the default expression language by editing the beehive-netui-config.xml file in your project. You'll find that file at a path such as the following:


Possible settings for default language include netuiel (for the JSP 2.0 expression language) and compat-netuiel (for the version 8.1 NetUI expression language. In other words, to change to the default to the JSP 2.0 expression language, change the file so that it includes the following:


Changing Code to Support the Expression Language in Beehive NetUI JSP Tags

If you choose to upgrade version 8.1 NetUI JSP tags to Beehive NetUI JSP tags, changes to your JSP code will include expression changes to support the expression language used by the Beehive tags. The following describes changes made by the tools during upgrade, as well as changes you might need to make to your own non-JSP code.

Expression Changes

The following changes are made to expressions during upgrade.

Changes Needed to Bind to Public Data Members

If you upgrade version 8.1 NetUI JSP tags to Beehive NetUI JSP tags, you may need to change how data held by public members is exposed to tags for binding. Whereas version 8.1 supported binding expression code to public fields, in Beehive expressions can only bind to public accessors.

In other words, although upgrade tools will upgrade the expression language syntax used in JSP tags, they will of course not add accessors to classes where needed. For a full upgrade to Beehive JSP tags, you must manually add get* and set* accessors where public fields were used.

Reserved Words Can Not Be Used as Identifiers

The JSP 2.0 expression language reserves the following words; your code should not use them as identifiers.

and    eq    gt    true    instanceof

or    ne    le    false    empty

not    lt     ge     null     div     mod

Note that you can inadvertently use a reserved word by including that word in the name of an accessor designed to expose a property to expression language code. For example, the following code would be designed to expose an empty property:

public String empty;
public String getEmpty() {return empty;}

In the JSP page, of course, this would result in using "empty," which is a reserved word, as a property name:

<netui:content value=?${pageFlow.empty}? defaultValue=?NO VALUE?/>

Instead, trying using a naming scheme that results in a method name such as "getEmptyVal", then bind to them with pageFlow.emptyVal.

For more information about the expression language, see Expression Language in the J2EE 1.4 tutorial.

Form Classes Must Include a Default Constructor

Unlike version 8.1, version 10.0 enforces a requirement that forms used in page flow (such as those which extended the now-deprecated FormData class) must have a default constructor.

You can work around this change by adding a default constructor after upgrading your code.

Updating XQuery Use to Support Upgraded XQuery Implementation

In version 8.1, XMLBeans supported XQuery Working Draft 16; Working Draft 23 is used in version 10.0. Upgrade tools will generally update XMLBeans code that executes XQuery expressions, but not code in JSP files. You will need to make the required change manually for code based on the older implementation to work.

For more information, see Updating XQuery Use to Support Upgraded XQuery Implementation.

Fixing Package Names That are Not Upgraded in JPF File Method and JSP Code

When a type name is fully-qualified outside a type import (Java or JSP), the type's package is not upgraded to the package used in version 10.0. For example, in the following after-upgrade code, note that the package for Forward has not been upgraded from com.bea.wlw.netui.pageflow to org.apache.beehive.netui.pageflow.

 * @jpf:action
 * @jpf:forward name="begin" path="Begin.jsp"
@Jpf.Action(forwards = {
    @Jpf.Forward(name = "begin",
                 path = "Begin.jsp")
public Forward begin()
    return new com.bea.wlw.netui.pageflow.Forward("begin");

The errors will be highlighted in source code. You can make fixes by using the Workshop for WebLogic quick fix feature to replace the type with the correct type of the same name. You can also search and replace to fix.

Custom Tags That Extend NetUI Tags are Not Supported

If you created custom JSP tags in version 8.1 by extending NetUI tags, your tags will not be upgraded by Workshop for WebLogic tools. Extending NetUI tags was not supported. Note that if you elected not to migrate NetUI tags to Beehive tags, your tags may build within the application, but may not work as expected.

Likewise, extending Beehive JSP tags in version 10.0 is not supported.

Details: Some PageFlowController and FlowController Methods Made Protected Instead of Public

To enhance application security, some public methods in org.apache.beehive.netui.pageflow.PageFlowController and org.apache.beehive.netui.pageflow.FlowController have been changed so that they're protected. This change means that these methods can no longer be invoked as bean properties from within JSP pages. In addition, new public versions of the methods were created for access from outside page flow code, but given names that begin "the" instead of "get" so that they're not accessible as bean properties.

In summary, this change includes the following:

In general, fixing broken code after upgrade involves searching for the method name that begins with "get" and replacing it with the corresponding method that begins with "the". For example, the following code would need to be revised:

PageFlowController pageFlowController =
if(pageFlowController != null){
    if(pageFlowController.getCurrentPageInfo().getForward().getRedirect() == true) {
        return new Forward("main_page");

The following reflects changes that would be made (note that the getCurrentPageFlow method above, from version 8.1, is deprecated; use the two-parameter version below instead):

PageFlowController pageFlowController =
         PageFlowUtils.getCurrentPageFlow(this.getRequest(), this.getServletContext());
// Note "theCurrentPageInfo" here where "getCurrentPageInfo" is used above.
if(pageFlowController != null){
    if(pageFlowController.theCurrentPageInfo().getForward().getRedirect() == true) {
        return new Forward("main_page");

Note that code written on versions of the Beehive APIs included in WebLogic Platform prior to version 10.0 might also need to be changed. Workshop for WebLogic upgrade tools do not upgrade code written on 9.x versions of the platform.

Upgrading from getRequest Method Calls to Retrieve a ScopedRequest Instance

In version 8.1, the return value of the FlowController.getRequest method could be cast to a ScopedRequest when running in the WebLogic Portal environment. In version 10.0, to improve performance the Beehive page flow APIs retrieve a ScopedRequest instance differently. This change is not upgraded by Workshop for WebLogic upgrade tools. If your portal code makes a call to this method, you will need to manually upgrade the code to avoid a ClassCastException. Your code should instead use the ScopedServletUtils.unwrapRequest method to retrieve the ScopedRequest instance.

For example, if your page flow code had the following:

ScopedRequest s = (ScopedRequest)getRequest();

you would change it to:

ScopedRequest s = ScopedServletUtils.unwrapRequest(getRequest());

Updating Code to Reflect Changes in PageFlowStack Class

Differences between the version 8.1 com.bea.wlw.netui.pageflow.PageFlowStack class and its Beehive counterpart in version 10.0, org.apache.beehive.netui.pageflow.PageFlowStack, may make it necessary for you to modify some of your code after upgrade. In particular, the version 8.1 class extended java.util.Stack, but the 10.0 class extends Object directly.

One scenario in which this could create a problem is if your code casts the return value of the static method PageFlowUtils.getPageFlowStack (which is a Stack object) to PageFlowStack. This cast is of course not valid with the Beehive PageFlowStack class. If you were casting to PageFlowStack, then using Stack methods, keep in mind that several of these methods are implemented in the Beehive PageFlowStack class; however, you now get the PageFlowStack instance using static PageFlowStack.get methods.

If you were directly calling the Stack instance returned from PageFlowUtils.getPageFlowStack, but you aren't casting to PageFlowStack, you can still use the Stack. Keep in mind, however, that the getPageFlowStack method is deprecated.

Updating Code to Reflect Changes in State Tracking API

In version 10.0, several methods in the NetUI API have been changed so that, under certain circumstances, they return IllegalStateException rather than null. This is an improvement over the version 8.1 API, in which null was returned regardless of whether the requested return value was actually null or simply unknown because it wasn't being tracked.

You can avoid handling IllegalStateException by overriding the alwaysTrackPreviousAction method in your page flow controller so that that method returns true. Note that this might negatively impact the performance of your application. Here's how it would look:

protected boolean alwaysTrackPreviousAction()
    return true;

The following is a list of affected methods:

The following lists detailed circumstances surrounding the change:

Replacing Callback-Enabled Controls Used in a Page Flow

In version 9.x custom controls used from a page flow can't receive external callbacks. In version 8.1, you could write a custom control that received callbacks from controls nested within it, such as service controls. By exposing a polling interface from your custom control, your page flow code could then retrieve responses received from the callbacks. This functionality is not supported in version 10.0.

In upgraded code, you can substitute for this functionality by replacing your custom control with a web service. For more information on the version 8.1 feature and suggested version 10.0 workarounds, see Providing Support for Callbacks from a Page Flow.

Ensuring Assembly of Controls Used from a JSP Page

In version 10.0, some controls require a compile-time assembly process that generates artifacts needed by the runtime. These controls include ServiceControl, EJBControl, and TimerControl.

This assembly process is only triggered for these controls when they're referenced within a Java file — effectively excluding controls that are referenced only from JSP pages. In upgraded code, you can work around this change from version 8.1 by referencing the control from a Java file.

The best place for this reference is the page flow controller file; if there's no controller in your application, you can add the reference to another Java file that's compiled with the application. You do this by adding an org.apache.beehive.controls.api.bean.ControlReferences annotation that names the control class used in the JSP page. Here's an example that references a single control:

public class Controller extends PageFlowController {

Resolving Name Conflicts Between Jpf.Forward and validationErrorForward

Version 8.1 allowed the jpf:validation-error-forward and jpf:forward annotations to have the same value for their name attributes; this is not allowed in version 10.0. For example, you might have had version 8.1 code such as the following, in which "failure" is used twice as a name attribute value:

 * @jpf:action
 * @jpf:forward name="success" return-action="addProfileDone"
 * @jpf:forward name="failure" path="addClient.jsp"
 * @jpf:validation-error-forward name="failure" return-to="currentPage"
protected Forward addClientProfile(MaintainIndividualProfileForm form)

The upgraded counterparts to this code (in the Jpf.Forward annotation and the Jpf.Action validationErrorForward attribute) will generate a build error in version 10.0. You can work around this change by changing one or both of the attribute values so they're not the same.

Upgrade Changes for Co-Location in Page Flows

Version 8.1 supported a project hierarchy in which the Controller file (Controller.jpf) and JSP files could be put into the same directory. This is not supported in version 10.0.

For example, during upgrade the following hierarchy change will occur for upgraded page flows:

Version 8.1


Version 10.0 (after upgrade)


The version 8.1 style is referred to as co-location. In version 10.0 (including for upgraded applications), JAVA source files and JSPs are kept in different directories. Note that if you create a new page flow called myPageFlow, it would feature two parallel directories called myPageFlow — one for JAVA source code and one for the JSPs. Here's a simplified example:

            other JSPs

Fixing Erroneous IDE Error for Variable in an HTML Start Tag

The version 9. 2 IDE incorrectly displays an error for code in which a variable declaration is made in an HTML start tag; the code is actually valid at run time. For example, in the following anchor tag the <%=s%> code using the String variable is flagged by the IDE as unresolved, but is actually valid:

<a href="<%! String s="test"; %><%=s%>">Test</a>

This also applies to WebLogic Portal tags that set Java variables, such as <render:getJspUri> and <render:getSkinPath>.

You can work around this in code upgraded from version 8.1 by moving the variable declaration to a line outside a start tag, as follows:

<%! String s="test"; %>
<a href="<%=s%>">Test</a>

Import and Use of com.bea.wlw.netui.util.XMLString are Not Supported and Will Not be Upgraded

This XMLString class (not to be confused with XMLBeans' org.apache.xmlbeans.XmlString) is not included in version 10.0. Upgraded code that imports the type will generate compilation errors. In version 8.1 this class was used in conjunction with the XScript expression language, which has been removed from version 10.0.

Related Topics

Changes During Upgrade from WebLogic Workshop 8.1 to Version 10.0


Skip navigation bar   Back to Top