|
|
|
|
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.
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:
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.
 |
 |
 |
||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||
 |
|
 |
During upgrade some JSP tag attributes may be migrated to new attributes, or simply removed. The following table describes possible changes.
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
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.
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:
WORKSPACE_HOME\PROJECT_HOME\web\WEB-INF\beehive-netui-config.xml
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:
<expression-languages>
<default-language>netuiel</default-language>
....
</expression-languages>
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.
The following changes are made to expressions during upgrade.
|
|
|
||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||
|
|
|
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.
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.
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.
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.
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.
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.
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 =
PageFlowUtils.getCurrentPageFlow(this.Request());
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.
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());
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.
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:
@jpf:forward with a return-to="previousAction" attribute.true, the version 10.0 methods will return
java.lang.IllegalStateException.true, then the version 10.0 methods will either return the requested value or null if the value is in fact null.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.
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:
@ControlReferences(value={mycontrols.MyServiceControl.class})
public class Controller extends PageFlowController {
...
}
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.
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
webapp/
Controller.jpf
index.jsp
Version 10.0 (after upgrade)
webapp
src
Controller.java
web
index.jsp
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:
webapp
src
myPageFlow
myPageFlowController.java
Controller.java
WebContent
index.jsp
myPageFlow
index.jsp
page1.jsp
other JSPs
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>
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.
Changes During Upgrade from WebLogic Workshop 8.1 to Version 10.0
 |