|
|
Before you attempt to upgrade a WebLogic Portal 8.1 SP4+ application to WebLogic Portal 10.2, you need to become familiar with the Workshop upgrade steps, and any related limitations. For complete information about upgrading your portal application in Workshop, see the Workshop for WebLogic upgrade.
The Workshop upgrade documentation assumes that your application was developed using WebLogic Workshop 8.1 SP4+. If it was not, you must refactor your code so that it builds and runs in the WebLogic Workshop IDE 8.1 SP4+ before using the tools described here to upgrade to Workshop 10.2.
This appendix focuses on topics that are specifically related to upgrading WebLogic Portal applications, and contains the following sections:
Webflows and pipelines were deprecated in WebLogic Portal 9.2 and are no longer supported; use page flows in place of these deprecated features.
The following sections describe some considerations and tips that might be useful when you upgrade portal applications, and it describes some situations where you might need to perform some manual tasks after upgrading your portal application.
This section contains the following topics:
Workshop provides a command-driven upgrade (upgradeStarter) and an ant task-based upgrade. WebLogic Portal does not support these upgrade alternatives; you must use the Import Wizard.
Unmodified Visitor Tools code from WebLogic Portal 8.1.4+ is upgraded as part of Import Wizard processing. However, the WebLogic Portal 10.2 communities-based components are disabled by default, because projects developed with 8.1.4+ are not communities-aware.
As part of the upgrade process, the Import Wizard creates a communities-config.xml file in the EAR project /META-INF directory that defines whether or not the communities-related Visitor Tools are enabled. To enable this functionality, set the flag in the enable-community-tools attribute to true, as shown in the following example:
<?xml version="1.0" encoding="UTF-8"?>
<communities-config xmlns="http://www.bea.com/ns/portal/100/communities-config">
<enable-community-tools>true</enable-community-tools>
Portal Look And Feels in WebLogic Portal 8.1.4+ used two configuration files for skins and skeletons (in the /skins/skin_name and /skeletons/skeleton_name directories): skin.properties and skeleton.properties. Both were text files, and skeleton.properties was optional.
In WebLogic Portal 10.2, both files are now XML.
For WebLogic Portal 10.2, it is necessary to use skin.xml and skeleton.xml to take advantage of new Look And Feel features, although you can still use legacy configurations. Upgrading your old .properties files is required.
To upgrade a WebLogic Portal 8.1 Look And Feel to the WebLogic Portal 10.2 format:
.laf file). WebLogic Portal automatically upgrades the associated .properties file; informational messages describe the change that occurs during upgrade. Figure C-1 shows an example:
WebLogic Portal 8.1 custom control annotation definitions are not upgraded to WebLogic Portal 10.2. The means for defining annotations is based on the Java 5 annotations model. To upgrade controls written for 8.1, you must rewrite the annotations definition in keeping with the new model.
For more information on upgrading your custom annotations, take a look at the Apache Beehive source code for its system controls. These provide annotations that use the new model.
For information on how the control context APIs have changed from WebLogic 8.1, see “Handling Context API Changes” in the Workshop online help.
If you optimized the thread pool used for an 8.1 application that uses forked rendering or forked pre-rendering, and you want to keep those optimizations in the upgraded application, you will need to perform some manual tasks after upgrading.
WebLogic Portal 10.2 uses WebLogic Server’s CommonJ WorkManager infrastructure for forked portlet pre-render and render. WorkManagers have similar but not identical configuration parameters, behavior, and deployment options. When you upgrade an 8.1.4+ application, any existing customizations to the portalRenderQueue thread pool will not be automatically applied to the default WorkManager used for forking. To tune this WorkManager, configure a WorkManager and associate it with the name wm/portalRenderQueueWorkManager. For more information about WorkManagers and thread usage in WebLogic Server 10.0, refer to “Using Work Managers to Optimize Scheduled Work” in the WebLogic Server documentation.
The Import Wizard includes the Struts 1.1 shared J2EE library for upgraded applications. The Struts 1.1 J2EE library is used to maintain the operability of your upgraded application; before an upgraded application can use Struts 1.2, any code in page flows or portlets with explicit dependencies on Struts 1.1 would need to be manually updated. (For more information, refer to Changes in Behavior Between Struts 1.1 and 1.2.
For new portal web projects, the Struts 1.2 shared J2EE library is included by default, but you can choose Struts 1.1 if desired. BEA strongly recommends that you keep the default setting to use Struts 1.2 with new applications. Even with upgraded applications, it would be beneficial to use Struts 1.2 if possible, and you might want to experiment with Struts1.2 to see if any explicit dependencies on Struts 1.1 actually exist.
WebLogic Portal support for Struts is slightly different if you upgrade to Struts 1.2.
Struts 1.1 support in WebLogic Portal will be the same as in previous releases, with the struts-adapter taglibs mapped to URIs using web.xml. In this case, you should use the struts-1.1.war J2EE library instead of the new struts-1.2.war J2EE library.
For applications upgrading to Struts 1.2, instead of mapping the struts and struts-adapter taglibs using web.xml, WebLogic Portal now relies on the JSP 1.2 implicit taglib mapping, wherein any .tld files in the META-INF directory in a JAR are implicitly mapped by the web container to the URI specified in the tld. In the case of WebLogic Portal, these are in struts-adapter.jar, in the path META-INF/tlds.
You can choose to use one of these two methods to upgrade to Struts 1.2:
http://bea.com/struts/adapter/tags-html and http://bea.com/struts/adapter/tags-nested for the HTML and nested taglibs, and http://struts.apache.org/tags-* for the remainder of the taglibs that the portal adapter does not override..tlds from both struts.jar (in struts-1.1.war) and from struts-adapter.jar and copy them to WEB-INF/tlds. This allows for the case where you want to continue using the explicit tld mapping via web.xml.
In past releases, WebLogic Portal used the configuration file url-template-config.xml for configuring the form of WebLogic Portal-generated URLs. WebLogic Portal now uses the Beehive equivalent: beehive-url-template-config.xml. The previous configuration file contained an element (generate-xml-amp-entity) that caused URLs to be generated with ampersand entities instead of characters for parameter separators, that is:
http://www...?arg1=foo&arg2=bar (entity)
http://www...?arg1=foo&arg2=bar (character)
In the absence of this configuration element, URLs were generated with ampersand characters.
The Beehive equivalent configuration element for ampersand entities is located in the NetUI configuration file, beehive-netui-config.xml. The Beehive default for ampersand entities is the opposite of the previous Portal default; in the absence of the configuration element, URLs are generated with ampersand entities.
Portal Framework now uses the NetUI configuration file as the source for this configuration element, and also uses the Beehive semantics. This means that by default, URLs generated by Portal contain ampersand entities. Note that this applies only to HTML configurations – XHTML configurations force ampersand entities in URLs, regardless of configuration setting.
If cases exist where you want to ensure that URLs are generated with characters rather than ampersand entities, you must add that configuration element to the beehive-netui-config.xml file.
Applications created using WebLogic Portal Version 8.1.4+ used the file META-INF/application-config.xml for configuration of various MBeans. In WebLogic Portal 10.2, MBeans have been changed to descriptor beans. Settings previously contained within application-config.xml are now in the appropriate descriptor bean configuration files, including:
When you import a Version 8.1.4+ application into Workshop, the import process performs the necessary conversion. For individual instances of the 8.1 application-config.xml file that you might want to use, you can right-click the file name in the Package Explorer to access the Upgrade context menu, which will convert the file.
In past releases of WebLogic Portal it was possible, though not recommended, to create more than one portlet category with the same name, at the same level in the hierarchy. In WebLogic 10.2, this operation is not permitted. (You can use the same name for more than one category, but they must not be “peers” in the hierarchy.)
When you upgrade a portal application to 10.2, any duplicate portlet category names that were used previously are preserved. It is extremely important that you edit these category names to be unique; otherwise the WebLogic Portal propagation tools might cause unexpected results, or errors might occur during the propagation process.
|