| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Platform > WebLogic Portal > Release Notes > Release 7.0 with Service Pack 7 |
|
Release Notes
|
Release 7.0 with Service Pack 7
Before you install and use release 7.0, review the following information:
What's New
Domains configured to run WebLogic Portal applications can now be configured to use the WebLogic Security Service introduced in WebLogic Server 7.0. Multiple authentication providers may be used, although certain administrative tasks are restricted to a single provider. For more information, see Switching to a WebLogic 7.0 Security Framework Security Realm.
Migration Information
WebLogic Platform 7.0 service packs incorporate service pack updates for all Platform 7.0 components (WebLogic Server, WebLogic Workshop, WebLogic Integration, WebLogic Portal and WebLogic JRockit).
If you developed applications using a prior version of the product, see http://download.oracle.com/docs/cd/E13196_01/platform/docs70/interm/migrate.html for information on making your previous data and customization available to the 7.0 release and its service packs.
Installation
For information about installing WebLogic Portal 7.0 and its service packs, see the Installation Guide at http://download.oracle.com/docs/cd/E13196_01/platform/docs70/install/index.htm.
Required Database Configuration Changes
To find information about database configuration considerations, see "System Administration" in the Administration Guide at http://download.oracle.com/docs/cd/E13218_01/wlp/docs70/admin/index.htm.
Disclaimer Regarding Use of Integrations
Use of WebLogic Portal in connection to and operation of third-party software, services and applications is entirely at the user's risk. BEA Systems, Inc. disclaims all liability and responsibility for the operation, accuracy and results of such software, services and applications.
Location of Supported Platform Information
Information about the supported hardware and software platforms, and related certifications, is available in "Supported Platforms" at http://download.oracle.com/docs/cd/E13196_01/platform/docs70/support/index.html. This information is updated as new platform certifications are completed. Refresh your browser cache to ensure you are viewing the latest content. The date of the file's last update is shown in the browser window's title bar.
Limitations Fixed
This section groups the known limitations that have been fixed for WebLogic Portal 7.0., 7.0 SP 1 - 7.0 SP 7. For more information, see the following sections:
Limitations Fixed in 7.0 Service Pack 7
No limitations were fixed for 7.0 Service Pack 7.
Limitations Fixed in 7.0 Service Pack 5 and 6
This section lists the limitations from previous versions of WebLogic Portal fixed in 7.0 Service Packs 5 and 6.
Limitations Fixed in 7.0 Service Pack 4 This section lists the limitations from previous versions of WebLogic Portal fixed in 7.0 Service Pack 4.
Limitations Fixed in 7.0 Service Pack 2 This section lists the limitations from previous versions of WebLogic Portal fixed in 7.0 Service Pack 2.
Limitations Fixed in 7.0 Service Pack 1 This section lists the limitations from previous versions of WebLogic Portal fixed in 7.0 Service Pack 1.
Limitations Fixed in 7.0 This section lists the limitations from previous versions of WebLogic Portal fixed in 7.0
Known Limitations and Workarounds in 7.0
This section groups the known limitations and workarounds for WebLogic Portal 7.0 issues by product area.
For more information, see the following sections:
E-Business Control Center Issues
This section lists the known limitations and workarounds stemming from issues involving the E-Business Control Center. In addition to the following table, see the following sub sections for more information:
Portal and Portlet Issues
This section lists the known limitations and workarounds for portal and portlet issues within the E-Business Control Center.
Portal Development and Administration Issues This section lists the known limitations and workarounds involving general portal administration issues.
Additional Information About CR109615 As a side effect of the fact that portlet webflows are now namespace aware (with the release of SP4) there is the possibility of a recursion problem in existing webflows particularly if they are based on pre-SP4 WebLogic Portal samples. The problem is best explained by example but might effect any webflow for a variety of reasons. The standard portal webflow you get when creating a new Portal Web Application contains, among others, a wild card refresh event, bea.portal.framework.internal.refresh, this event is routed to the preProcessor (com.bea.portal.appflow.processor.PreProcessor) which passes it through to the postProcessor component (com.bea.portal.appflow.processor.PostProcessor). Regardless of event type postProcessor then attempts to refresh all portlets in the portal. In the case of the 7.0 SP2 e2e sample's b2c application, the problem starts when an error is encountered during the processing of the catalog portlet webflow, in particular the addProductItemToShoppingCart pipeline component. When the pipeline component throws a PipelineException the catalogportlet webflow routes itself to a Proxy Node called portal_error which is a proxy for the error presentation node (error.jsp) in the portal namespace and the standard webflow error page is displayed. All the other errors in this webflow are also routed the same way. If the user then attempts to hit the Products tab on the portal again, URL - http://localhost:7501/b2cPortal/application?origin=hnav_bar.jsp&;event=bea.portal.framework.internal.refresh&pageid=Products, the portal refresh event is triggered (bea.portal.framework.internal.refresh) eventually resulting in the postProcessor attempting to refresh all the portlets. When the catalogportlet is refreshed (bea.portal.framework.internal.refresh) its webflow, catalogportlet, still has the state from the error above, that is it is at the error.jsp in the portal namespace. Webflow executor sees no refresh event specific to the portal error node so it falls back and uses the wildcard which results in a trip back to the postProcessor where the portlets are refreshed and on and on until the stack overflows. You can sometimes escape from the problem sometimes if you can find another entry point to the catalogportlet webflow. For instance in the e2e application at the bottom of the My Avitek page there are product links that will get you back into the catalog and put the catalogportlet webflow back into a workable state. The best way to fix this is to change the error page in each webflow. Instead of routing the flow to the portal namespace and using its error node, create an error presentation node in each portlet namespace and use the same error.jsp. Then each portlet will be able to recover using its own refresh path. In general it is not a very good idea to ever route a portlet webflow into the portal webflow. If you do you'd need to provide some means of returning gracefully. The samples shipping with SP4 have been updated this way. There are some exceptions such as the lastContentUrl node which does not result in the webflow changing namespaces as its function is to bring back the last state of the portlet. In addition it is conceivable that a set of webflows could be constructed in such a way that a portlet webflow might be successfully routed into a portal flow and eventually back but great care should taken and most likely would require at least one special processor be written that has the awareness to accept such routing and deal with getting the flow back to its original namespace. The e2e's b2c application's login process illustrates how crossing webflow namespaces can be useful and even necessary. This process involves three webflows starting with security.wf. If login succeeds the webflow routes through to user_account.wf finally ending up in the portal namespace where the portal is displayed. In this case this path makes sense since the login process is essentially a one way path to the portal page. Further there is a way to re-enter this webflow by hitting the logout button. Another feature that distinguishes the login webflows from the one that caused the stack overflow is they are not associated with a specific portlet. This, and understanding the refresh mechanism, are key points in avoiding the recursion problem. Recall the problem arose when a portlet's webflow ended up in the portal namespace with no way back. When the portal refresh event occurred, the portlets are refreshed but since the portlet's webflow was in the portal namespace it followed the portal refresh path leading back to an attempt to refresh the portlet and thus a recursive loop. Browser Issues This section lists the known limitations and workarounds involving browser issues.
System Administration Issues This section lists the known limitations and workarounds for general system administration issues. In addition to the following table, see the following sub-sections for more information:
Workaround for CR086602 You should do this in your applications and also in the domain wizard templates. You can find the EJB JAR files by searching your entire product installation dir for them. In addition to changing the role mappings you need to update the list of ProtectedGroupNames in the UserManager EJB deployment descriptor, META-INF/ejb-jar.xml, in usermgmt.jar. To change a role mapping for an EJB you must extract META-INF/weblogic-ejb-jar.xml from the EJB JAR, edit the group names in the security role mappings, and update the EJB JAR with the new META-INF/weblogic-ejb-jar.xml. Be careful about using a command like "jar uvf campaign.jar META-INF/weblogic-ejb-jar.xml" if your working directory is deeply nested. The jar command cannot handle this if the path to your working directory is too long. You may have to copy the JAR files to a directory close to your root dir to do the updating and then copy the updated JARs back into the J2EE app dir. To change a role mapping for a web application you must update the security-role-assignments in WEB-INF/weblogic.xml. For an example, here is a list of EJB JARs for the sampleportal J2EE application in 7.0 Service Pack 1 that contain role mappings that must be updated:
Do not forget to change the ProtectedGroupNames env-entry in META-INF/ejb-jar.xml: usermgmt.jar
For an example, here is a list of the web applications for the sampleportal J2EE application in 7.0 Service Pack 1 that contain role mappings that must be updated: datasync, tools, toolSupport. Do not change these role mappings around for an existing installation that has existing Portal delegated administrators. First you should log in to the Portal JSP admin tools as a WebLogic Server System Administrator or a Portal System Administrator and delete all Portal Administrators and Group Administrators.
After you reconfigure your server to accept the new group name mappings, then you can create all of your Portal Administrators and Group Administrators using the Portal JSP administration tools.
Internationalization Issues
This section lists the known limitations and workarounds for internationalization functionality.
Migration Issues This section lists the known limitations and workarounds for migrating from an earlier version of WebLogic Portal to 7.0.
Miscellaneous Notes
This section includes a description of issues that do not have a workaround at this time. For example, some issues involve third-party defects or WebLogic Portal 7.0 feature clarification.
Because properties in the CustomerProperties property set cannot be set to null for a user of type wlcs_customer, this type of user cannot inherit from a default value in the property set. This does not affect non-customer profiles, nor does it affect any other properties of customer profiles.
While the WebLogic Portal Administration Tools do display inherited default values for the CustomerProperties property set, a getProperty call returns an empty String if you set values in CustomerProperties to null.
TABLE COLUMN LOB TYPE/SIZE
P13N
SAMPLE_UUP_INFO USER_INFO CLOB(8K)
DATA_SYNC_ITEM XML_DEFINITION CLOB(500K)
AD_BUCKET AD_QUERY CLOB(25K)
MAIL_MESSAGE MESSAGE_TEXT CLOB(25K)
PLACEHOLDER_PREVIEW XML_DEFINITION CLOB(25K)
ENTITLEMENT_RULESET RULESET_DOCUMENT CLOB(256K)
CATALOG_PROPERTY_VALUE BLOB_VALUE BLOB(8K)
PROPERTY_VALUE BLOB_VALUE BLOB(10K)
WLCS
DISCOUNT DISCOUNT_RULE CLOB(8K)
EVENT/BEHAVIOR TRACKING
TABLE EVENT XML_DEFINITION CLOB(200K)
A configuration using PointBase as the database the E-Business Control Center Discount Editor Trigger Items Browse function is slow.
The PointBase database demonstrates some out of the box functionality available in WebLogic Portal. Performance of some functionality such as catalog browsing in the commerce templates may be better demonstrated through other databases that require additional setup.
If you have two different portlets on a portal page calling the same web service, the web service fields are populated with the same information.
For example:
If you create two different portlets with the portlet wizard that call the web service Federal Express Tracking, add both portlets to the same portal page, open the portal in the browser, type in a tracking number "12345" in one of the portlets and submitted it, the tracking information for "12345" appears in both portlets.
<Oct 15, 2001 5:40:12 PM MDT> <Error> <Usermgmt> <Password change failed for
user testuser1>
Runtime Error...
Remote exception UserManager
Stack Trace...
com.bea.p13n.appflow.exception.ProcessingException: Remote exception
UserManager at
com.bea.portal.appflow.processor.security.SetPasswordFormProcessor.setPassword(SetPasswordFormProcessor.java:145)
at. . .
This problem occurs when a method in a class calls another method in the same class or one of the class base's classes. This is typically done by simply calling the method, for example "getValue()" (as apposed to "variableName.getValue()" or "ClassName.getValue()" type of call).
The code migrator correctly interprets the call as "this.getValue()", but then it looks at all the implements and extends statements it encounters in the file being processed and assumes that they could have only come from the class definition itself. (This assumption is bad if for instance an inner class extending another class was defined in the same file.) The first of these statements that has any kind of map entry is assumed to be the required annotation for the method. This problem appears in a variety of ways depending on the source file being analyzed.
For example, if the class being analyzed extends a class or implements an interface that has been modified, or even just specified as needing a notation in some map file, this problem can appear. The method will always be annotated even if it was defined in the sub-class and not the class or interface actually specified in the map.
Another example that illustrates this problem appears when a class is defined in which some inner classes are defined that extend or implement a class that is referenced in one of the migration maps. See the following snippet from Test class which illustrates this issue:
public class Test {
public void testExtendsImplements() {
class MinorCowboys extends Cowboys {
}
class HighSchoolCowboys extends nfl.dallas.Cowboys {
}
class Raiders implements Cowboys {
}
class MinorRaiders implements nfl.dallas.Cowboys {
}
...
public void testMethods() {
Cowboys cowboys = new Cowboys();
cowboys.pass(100,"HailMary");
cowboys.run(100,"Middle");
String s = Cowboys.getStadiumName();
s = nfl.dallas.Cowboys.getStadiumName();
int i = Cowboys.stadiumZipcode;
testReturns();
}
public void testReturns() {
class ReturnTest {
public Cowboys getCowboys() {
return new Cowboys();
}
public nfl.dallas.Cowboys getMoreCowboys() {
return new Cowboys();
}
public FootballTeam getFootballTeam() {
return (FootballTeam) new Object();
}
}
}
}The call to Test class's testReturns() method in the Test class's testMethods() method. Even though the maps make no reference to this method or even the Test class, this method may still end up annotated. First assume that nfl.dallas.Cowboys is referenced in a code map. Then because of the inner class definitions, near the top of Test class that extend or implement nfl.dallas.Cowboys or Cowboys, the code migrator mistakenly assumes that testReturns() is part of the class nfl.dallas.Cowboys. So the result is that the method testReturns() from Test class gets the class level annotation specified for the Cowboys class.
In Portlet Wizard in the E-Business control center, if you select the option to deliver the portlet with a webflow the portlet is defined with the entry <webflow-filename>delete</webflow-filename>. Therefore, a webflow is defined.
If you delete the webflow in the E-Business Control Center and open the associated portlet Editor window it shows a webflow selection of None. But he portlet.xml file still contains the <webflow-filename>delete</webflow-filename> entry. The portal returns an exception if it is accessed in this state.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||