Last Updated: | July 29, 2005 |
Status: | Production |
Version: | PDK Release 10.1.2.0.2 |
System Requirements
Release 10.1.2.0.2
Release 10.1.2.0.0
Release 9.0.4.1.1
Release 9.0.4.1.0
Release 9.0.4.0.2
Release 9.0.4.0.0
Release 9.0.2.6.2
Release 9.0.2.6.0
Release 9.0.2.4.0
Release 9.0.2.0.2
Release 9.0.2.0.1
Release 9.0.2.0.0
Installation
Known Issues
The following are the recommended and minimum requirements to use and install this release of PDK-Java
Note: Starting with PDK 9.0.4.1.0, the PDK download is intended to be installed and deployed in a standalone OC4J instance only. If you plan to use PDK in an Oracle Application Server instance, you must get and install the corresponding Oracle Application Server releases or patchsets.
Application Server | Standalone OracleAS Containers for J2EE (OC4J) 10g (9.0.4) only |
OracleAS Portal Version | 3.0.9.8.2 (and later). Some functionality may require a later release of OracleAS Portal |
Browsers | Netscape 4.0.8 and above, Microsoft Internet Explorer 4.0.1 with Service Pack 1 and above |
Note: You may encounter JavaScript errors when using a browser older than what is listed above
Resource links may now be rendered using the PDK-Java API method, oracle.portal.provider.v2.url.UrlUtils.constructResourceURL, that proxy via the page engine. This feature allows for cases where the URL of image links in a portlet reside on a server that is only available within a firewall. This feature is only compatible with versions 10.1.2.0.2 and later of the page engine. In an environment that doesn't support this feature, direct links will be rendered.
The feature embeds the resource URL inside a page url. To prevent spoofing of the embedded resource URL, a signature authenticates page engine requests for resources. The shared key to generate this signature must be specified in two places.
The Struts renderer has had some changes made to it::
Other fixes
API additions have been included which allow portlet customizations to be exported and imported by OracleAS Portal's export/import utilities. An implementation of those APIs is also included such that default portlet customizations are maintained when a portal page group or page is exported and imported. Note: this feature also depends on new functionality in OracleAS Portal version 10.1.2. Therefore, for PDK-Java based portlets to participate in export/import, both OracleAS Portal and PDK-Java must be 10.1.2.x versions.
The API additions, and new classes supporting the default implementation, mean that portlet customizations are sent back to the calling portal obfuscated in a SOAP message. For more information on how to augment, or otherwise override, the default behaviour, consult the Portlet Developer's Guide accompanying OracleAS Portal release 10.1.2.
If your portlet persists sensitive data to the preference store, you may wish to switch off the default export/import behaviour when upgrading to PDK-Java 10.1.2.0.0 while you consider the security implications. To accomplish this, include the following JDNI environment entry in your web application's deployment descriptor, web.xml:
<env-entry>
<env-entry-name>oracle/portal/provider/global/transportEnabled</env-entry-name>
<env-entry-value>false</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>
A full discussion of security features of the API additions can be found in the Portlet Developer Guide accompanying the OracleAS Portal 10.1.2 release.
This API alteration only affects specializations of oracle.portal.provider.v2.http.DefaultProviderLoader which overide the init method. The signature of this method has changed from
init(Map, SOAPContext)
to
init(Map)If your specialization relied on the features of the SOAPContext supplied in the old method signature, your workaround is to use the static accessors of the new class oracle.webdb.provider.v2.adapter.SOAPContext. However, this class is considered a non-published API so usage is discouraged.
Release 9.0.4.1.1 does not add any functionality over and above that included in the 9.0.4.1.0 release.Iit is primarily a maintenance release supporting the accompanying Portal Tools release.
To simplify the configuration and upgrade requirements for all our sample portlets, we now use a localePersonalizationLevel of none in all the XML Provider Definition (provider.xml) files we ship in jpdk.ear. This means that the changes you make in Edit Defaults mode will apply to all users, no matter what their or your Portal session language is. If you want to use the samples with existing locale-specific data from previous releases and continue using the old Edit Defaults behaviour, simply modify the localePersonalizationLevel tag to a value of language or locale appropriately (see 9.0.4.0.2 Notes for a description of these settings). If you are upgrading from a release prior to 9.0.4.0.2, you should also use the upgrade utility described below to ensure existing locale-specific data uses an appropriate naming format for your chosen localePersonalizationLevel.
A new command line utility has been included in pdkjava.jar that allows users upgrading from previous releases of PDK-Java and OracleAS Portal to manage portlet preference data generated by existing portlets. The tool allows upgrading users to ensure that their existing locale specific portlet preference data uses a naming format compatible with the latest PDK and Portal releases, and also allows users to migrate existing data between different preference stores (e.g. from FilePreferenceStore to DBPreferenceStore).
The utility supports 6 basic modes, specified by the -mode option. Two of these are "upgrade" modes where data is upgraded in place. These are
The upgrade modes can be used to modify existing locale specific preferences in the preference store so that they use a naming format compatible with the current Portal and a given localePersonalizationLevel setting (added in Release 9.0.4.0.2). They would typically be used in the following scenarios:
If you specify one of the upgrade modes, you must use the -remap option to specify which localePersonalizationLevel (language or locale) that you are upgrading to. You may also use the -countries option to specify a prioritized list of ISO country codes, indicating your order of preference should any 'collisions' between remapped preferences for different countries occur. For example, if you specify "-remap language -countries GB,US", it means that should the utility come across both US English and British English preferences (en_US and en_GB) in a given preference store, it will remap the British English preference to become the English-wide preference (en) and leave the US English preference alone.
The other four basic modes are "migration" modes in which data is copied from a source preference store to a target preference store. These are
If specifying one of these migration modes, you may also (but need not) use the -remap and -countries options described above to specify that the data should be upgraded in the course of being migrated, i.e. locale-specific preferences should be remapped appropriately.
The other options accepted by the utility are used to specify the properties of the preference store(s) involved in the upgrade or migration operation. These should correspond to the tags you would use in provider.xml to describe the preference store(s).
Properties beginning with the prefix "-pref1" correspond to properties of the source preference store (in an upgrade mode, this is of course the only preference store). So, for example, specifying "-pref1UseHashing true -pref1UseHashing true -pref1RootDirectory j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sample" would set the useHashing and rootDirectory properties of a source FilePreferenceStore. Similarly, when one of the migration basic modes has been selected, properties beginning with the prefix "-pref2" correspond to properties of the target preference store. So, for example, specifying "-pref2User portlet_prefs -pref2Password portlet_prefs -pref2URL jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid" would set the database connection details on a target DBPreferenceStore. Consult the XML tag reference for more information about the properties you can set on a PreferenceStore.
For a complete description of the command line syntax for the migration tool, just invoke the command "java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar oracle.portal.provider.v2.preference.MigrationTool" once you have installed PDK Java in an OracleAS or OC4J Oracle home. Below are some example usages:
The PDK-Java now provides more control over how much information from the portal session language is used when writing/reading default portlet customization data. Prior to release 9.0.4.0.2, all such available information was used when writing/reading default values (for anything other than the portlet's default locale). For example, if a portlet's defaults were edited by a user in locale "en-US" and by a user in "en-GB", those default customizations would always be stored separately. Using a new setting, the locale personalization level, the PDK-Java can now be instructed to write/read this type of customization with only the language code, with both the language and country code, or not at all.
The locale personalization level may be set using either PortletDefinition.setLocalePersonalizationLevel(int) or ProviderDefinition.setLocalePersonalizationLevel(int) using constants defined in PortletConstants. If the XML Provider Definition technology (provider.xml) is being leveraged, a new tag, <localePersonalizationLevel>, may be included at portlet or provider definition level with portlet level settings taking precedence over the provider level. For example,
<portlet class="oracle.portal.provider.v2.DefaultPortletDefinition">
...
<name>StockQuotePortlet</name>
<title>StockQuotePortlet</title>
<localePersonalizationLevel>language</localePersonalizationLevel>
...
</portlet>
Possible values for <localePersonalizationLevel> are:
If omitted from the provider/portlet definition, the locale personalization level defaults to language. Thus, to recover localized defaults written with a release prior to 9.0.4.0.2, it is necessary to explicitly set this to locale. Note: this setting in no way affects user level customizations, only what defaults a user will see before customizing the portlet for themselves.
The PDK-Java SOAP servlet now supports an extra deployment property called
testPageURI that allows you to specify a path to a
resource to be used to render the markup that is returned in response to an
HTTP GET request to the provider's base URL (http://<host>:<port>/jpdk/providers/<service
name>), commonly known as the "test page". This allows you
to configure your own servlet or JSP to act as the test page for your providers.
Like all other deployment properties, this setting can be controlled by adding
an appropriate line to the <service name>.properties
file in the WEB-INF/deployment directory of your web
application. For example, in sample.properties we
have the line:
testPageURI=/htdocs/testpage/TestPage.jsp
A sample test page JSP is now included in jpdk.ear that uses UIX technology to render the provider test pages with a standard Oracle "look and feel".
PDK-Java now provides integration with the Apache Struts framework through a new renderer class called StrutsRenderer. For more information, refer to the article Using the Struts Sample.
Release 9.0.4.0.0 does not add any functionality over and above that included in the 9.0.2.6 releases. However, it does include changes necessary to be compatible with the OracleAS 10g technology stack.
Release 9.0.2.6.2 is primarily a maintenance release supporting the accompanying Portal Tools release.
PDK-Java no longer interrupts threads which have been processing a single request for a long time. This behaviour could cause a JSP compilation thread to halt prematurely, resulting in invalid class files. Instead, verbose log messages are written to serve as warnings to the administrator.
PDK-Java now integrates with OID allowing you to obtain user profile and group information from your OID server. This built-in integration allows you to obtain user profile information via the ProviderUser class and includes methods to determine if the current user belongs to a specific group. In addition to ProviderUser, the PDK-Java also provides a Security Manager that lets you secure your portlets based on portal groups.
If you need access to other information stored in your OID server, you can obtain a connection to the OID server which you can then use to query custom data.
This feature requires OracleAS Portal release 9.0.2.6 or later
Earlier releases of PDK-Java included deployment-specific configuration information in several locations including the provider definition file, the web application's web.xml file and the provider's deployment properties file. The problem with these approachs is that all these files are included in a provider WAR file. This means that in order to configure a provider for a specific deployment, you had to know how OC4J deploys applications and then update the configuration settings after you have deployed the provider.
In production environments, this is likely to require the intervention of multiple people to get access to the correct files and then there is always the risk of corrupting one of the files.
In this release of the PDK-Java, all the settings that you might want to modify are exposed as JNDI environment variables. This means that they can all be set via OracleAS Enterprise Manager (OEM) or, if your OC4J instance is not managed by OEM, by updating the orion-web.xml file.
PDK-Java now includes a comprehensive set of provider validation rules that are checked whenever a provider definition is loaded. The validation system does not stop when it finds the first error, unlike older releases, but validates as much of the provider as it can, reporting the errors via the Provider Test Page and log files. The goal of the provider validation system is to catch any and all errors that might cause your provider to fail either during registration or at runtime.
PDK-Java now automatically invalidates portlet content cached in Web Cache whenever you customize a portlet. This feature is enabled by specifying the <autoInvalidate> tag in your provider definition file. A typical entry for a portlet that uses invalidation caching with auto-invalidate enabled might look like this:
<renderer class="oracle.portal.provider.v2.render.RenderManager">
...
<useInvalidationCaching>true</useInvalidationCaching>
<pageExpires>5</pageExpires>
<autoInvalidate>true</autoInvalidate>
...
</renderer>
This feature requires OracleAS Portal release 9.0.2 or later
In earlier releases of PDK-Java, ResourceRenderer could only read static files encoded in ISO-8859-1. You can now specify the encoding ResourceRenderer should use when reading static files using a similar mechanism to that used by FileRenderer. For example, to render a static HTML file that is encoded in UTF-8, you would use the following:
<renderer class="oracle.portal.provider.v2.render.RenderManager">
...
<showPage class="oracle.portal.provider.v2.render.http.ResourceRenderer">
<resourcePath>/path/to/file/utf8.html</resourcePath>
<charSet>utf-8</charSet>
<contentType>text/html</contentType>
</showPage>
...
</renderer>
Earlier releases of PDK-Java took values entered in a provider definition file literally - including any whitespace that might be between the value itself and the opening/closing XML tags. Even though this is standard XML parsing behavior, some people found it inconventient. Consequently, the default behavior is now to trim all whitespace from the value returned by the XML parser.
If you want to retain the whitespace surrounding a specific value, you can do so by including the attribute "trim=false". For example:
<description trim=false> I
want extra white space </description>
<description> I
don't want any white space </description>
PDK-Java now lets you specify a portlet's cache level on a per-portlet basis. Previously the cache level used to cache portlet content was determined by the registration settings of the Web Provider.
The supported caching levels are:
You can define the cache level for a portlet via the provider definition file by specifying a cache level tag at either the portlet level, the provider level or both. If cache level is specified at both the portlet and provider level, the portlet level takes precedence. If no cache level is specified at any level, the default will be User. For details on the provider definition file entries, please refer to the Provider Definition File Tag Reference.
This feature requires OracleAS Portal 9.0.2.5 or later
In previous v2 releases, portlets using JSPs or Servlets were always invoked using the RequestDispatcher.include() method. This meant that included JSPs or Servlets could only invoke other JSPs or Servlets using the include() method. However, some MVC frameworks use the RequestDispatcher.forward() method to forward a request from a controller to the JSP or Servlet that will handle the actual request. Consequently, these frameworks could not be used in conjunction with the PDK-Java.
PDK-Java now invokes all JSPs and Servlets using the RequestDispatcher.forward() method. This allows you to use MVC frameworks to implement your portlets. Any portlets that use include() method will continue to work as before.
You can now build portlets that utilize Edge Side Includes (ESI) to construct a portlet from multiple parts. The portlet itself generates the ESI "framework" of the portlet and the "pieces" are requested separately and merged into the portlet by OracleAS Web Cache. This allows you to build portlets that consist of a combination of dynamic and static content. The different pieces can be cached independently by Web Cache allowing you to optimize cache usage and minimize the amount of content that must be generated by the web provider for each request.
The new ESI Portlet included in the Invalidation Web Provider demonstrates this feature.
This feature requires OracleAS Web Cache release 9.0.2 or later
In previous releases, creating a partner application required you to use the SSO SDK to create application SSO session cookies. However, you can now use mod_osso to protect your partner application and mod_osso will automatically challenge unauthenticated users for you. Now you can focus your attention on the integration between the Web Provider and the application rather than the process of making your application an SSO Partner Application.
The new Partner Application Sample demonstrates this feature.
The LogManager utility, which is used for logging within the PDK-Java, has been enhanced to allow Web Providers installed in different web applications to write log messages to different application log files regardless of which class loader is used to load it. Previously, if ptlshare.jar was included in the system classpath, all log messages would go to 1 log file. Log messages for a specific web application will now always go to the application.log associated with that web application. You can also configure different log levels for each web application.
You can now record performance statistics in the provider log file or view them in your web browser beneath each portlet.
To enable this feature, set the logging level in your web.xml file to "performance" level (a value of 5 or higher). Each performance log entry consists of a label, [perf-provider], followed by a list of name-value pairs separated by spaces. The log entries always follow the same format regardless of the operation that was timed - all operations are timed, not just "show" calls. The consistent format simplifies parsing of the entries for performance analysis. If an attribute is not relevant or a value was not captured for a request, a value of '(null)' is recorded. The attributes recorded for each request are listed below.
Performance statistics can also be viewed in the portal page itself by appending "&_debug=1" to the page URL displayed in your web browser's address window. A summary of the performance statistics and caching information are displayed below each web provider portlet.
Note: If your portlet is using caching, this information will be cached along with the portlet so the same information will be displayed whenever that cache entry is used. This means the statistics represent the time taken to generate the original content. The time taken to retrieve the cached copy is displayed below the portlet generated information. Even though the information is cached, other users will not see the cached copy unless they have also appended "&_debug=1" to their page URL so you need not worry about the use of this functionality impacting other users of your portal.
This is a new feature that monitors the execution of portlet requests and either logs a warning message if a portlet does not complete execution within a specified "warning timeout" or attempts to interrupt a hanging request if that request exceeds a specified "kill timeout". Portlets can also monitor their own execution with regards to the "warning timeout", voluntarily terminating themselves if the timeout has expired.
Real world experience has shown that it is possible for a single poorly performing portlet to literally bring an entire portal to its knees. When the Parallel Page Engine (PPE) makes requests to web providers, it has a request timeout mechanism. If a portlet request does not complete within that timeout, the PPE stops waiting for the portlet and returns the page to the user without it. However, the web provider cannot be notified of this condition and continues executing the request. The PPE continues to make new requests for the slow portlet, each time having to wait for the full timeout period to expire before returning the incomplete page. At the same time, requests for the slow portlet consume more & more resources on the provider's application server and begin slowing the execution of other portlets. Over time, more page requests are impacted as requests become backed up on the provider machine - the more requests are backed up, the more PPE resources are tied up waiting for requests to complete and page requests start getting backed up. Eventually new page requests are refused by the PPE effectively making the portal inaccessible.
This feature, along with other features in the PPE, aims to protect your portal from poorly performing portlets that can cause this type of denial of service. The "warning timeout" lets you identify portlets that consistently fail to meet performance targets and the "kill timeout" attempts to interrupt any requests that appear to be hanging.
It is a good idea to set aggressive performance goals for your portlets using the "warning timeout". This will allow you to identify portlets that do not meet your performance goals and need to be tuned. Requests that do not meet the target are not impacted - the framework simply writes a message to the log files. This means you can set and monitor aggressive goals without needing to worry those goals impacting your portal. Over time, you can address the consistent "offenders" and improve the overall performance of your portal.
Both the timeouts are specified in seconds in the provider's .properties file using the following properties:
The "kill timeout" should be larger than the "stall" time in the PPE to ensure that the PPE is no-longer waiting for the request to complete when the framework attempts to interrupt the request.
The framework also provides an API that portlets can use to monitor their own execution with regards to the warning timeout. If the API indicates whether the allowed execution time has elapsed and can be called after performing potentially time-consuming operations (such as reading/writing files or accessing a database). If the timeout has expired, the portlet can halt further processing, release any resources it is holding and exit as quickly as possible. If your portlets utilize this feature, you should set the warning timeout to be slightly larger than the PPE's stall time to ensure that your portlets only terminate themselves after the PPE has stopped waiting for the request to complete. The new API is
PortletInstance.hasTimeoutElapsed()
All Web Provider log file entries are now prefixed with context information. This makes the log entries longer, but it also makes the log files much more useful since you can easily identify all the log messages for a particular portlet request - even when they are interleaved with many other portlet requests. The context information added to each message consists of:
The combined context information, which is enclosed in square brackets, can be used to quickly locate all the log entries for a particular portlet request. This is done by locating all the log entries that share the same context information. Previously, this was very difficult to do - especially in a high-volume environment. The originating page request id can also be used to:
A new XML Tag Reference document has been added to the PDK. The provider definition file does not have a DTD or XML schema definition because it is designed to be extensible based on the implementation classes it references. Different implementations of the interfaces or abstract classes will often require different configuration information.
The Tag Reference describes the predefined tags for all the known implementation classes that are included with the PDK-Java. The document is structured similar to Java Doc, describing the purpose and form of each tag along with a list of known implementation classes for that tag (if appropriate). Clicking on a known implementation will take you to the tags that are specific to that implementation class. Using this document you can quickly discover all the configuration parameters that are available for each implementation class.
Two classes for accessing and rendering Web Services were added to the PDK-Java in the 9.0.2.0.1.release. These classes have now been promoted to "production" status and will be supported as production level components of the API.
URL Services was upgraded to work with the v2 API and released as a "Beta" component in the 9.0.2.0.0 release, This component has now been thoroughly tested and promoted to "production" status.
Two new renderer classes, RPCWebServiceRenderer and DocWebServiceRenderer, have been provided to allow easy integration of web services into your portlets. For more information, refer to the article Installing the Web Services Sample Portlets.
The Web Services Renderers are introduced as beta level features.
Note: If you want to generate your own Java stubs to use with RPCWebServiceRenderer, you will also require Oracle JDeveloper Release 9.0.2 or later
This release of the PDK-Java includes 2 versions of the web provider framework, version 1 and version 2. Version 1 of the framework is basically the same as PDK-Java 3.0.9, with some additional features for supporting delivering content to mobile devices. Version 2 of the API is evolution the includes migration to the OC4J platform and some API changes designed to promote stability and extensibility of the API.
There have been a number of changes since the last major release of the PDK-Java. The changes fall into 3 categories:
One of the biggest changes in the PDK-Java is the migration from the JServ servlet engine to Oracle Containers for Java (OC4J). OC4J is a J2EE compliant application server that supports J2EE components, Servlets and JSPs. For the PDK-Java, the biggest impact of this migration is the switch from the Servlet 2.0 to the Servlet 2.2/2.3 API. This API change impacts the way a provider is deployed, which is discussed in more detail later in this document, and the way in which JSPs and Servlets are invoked by the framework.
PDK-Java now uses the RequestDispatcher service provided by the Servlet 2.3 API to invoke JSPs and Servlets instead of the custom approach used in earlier releases. This means that the functionality of several renderers has been merged into a single renderer - ResourceRenderer.
PDK-Java v9.0.2 includes several changes that are designed to increase the overall stability of the framework and make it easier to introduce new features with minimal impact on existing code. These changes include:
During the development of earlier releases of the PDK-Java, it became evident that the use of Java interfaces to define top level APIs made adding new features difficult. This was because new features often required API changes and those API changes had to be reflected in changes to the Java interfaces. For developers using the default implementations, these changes were not invasive. However, for developers writing more complex providers, any interface change potentially caused their code to break because their implementations no-longer matched the interface definitions.
To resolve this issue most of the Java interfaces have been replaced with abstract classes. The switch to abstract classes allows new features to be added without breaking any existing code. While this change does reduce flexibility a little (due to the lack of support for multiple inheritance in Java) and requires code changes to adopt the new release of PDK-Java, we feel that the the long term gains in stability are worth the cost.
In addition to replacing Java interfaces with abstract classes, the package structure of the JPDK has been modified to include a new version number and to organize the classes based on functionality.
All packages now include "v2" in the package name to indicate that the package belongs to version 2 of the the PDK-Java. The inclusion of a version number in the package name allows different versions of the PDK-Java to be included in the same classpath without worrying about collisions.
In addition to the version number change, the classes have been re-organized into a more logical structure. The new structure groups classes based on functionality. This makes it easier to find existing classes and organize new classes as new functionality is added.
To make the code more understandable for developers and create a clean separation between the provider APIs that developers implement and the underlying code that communicates with OracleAS Portal, the provider and portlet interfaces have been modified.
Previously, the provider and portlet APIs were not very object-oriented and API calls from the communication layer of the framework sometimes bypassed these objects and accessed the "controller" objects directly.
In the new API, several changes have been made:
Splitting the information in this way makes the usage of the classes clearer for developers and allows a single set of metadata to be shared by many registered instances. It creates a platform for supporting provider instance specific behavior (for example provider configuration settings that are specific to a registered instance of that provider)
The old Portlet interface really represented only the portlet metadata. All API calls that affected a portlet were actually routed directly to the appropriate controller. This architecture did not create a clean interface with the communication layer of the framework and made it difficult for developers working with more complex portlets to understand the flow of control within the framework.
To rectify this problem, the PortletInstance and PortletDefinition were created. The PortletDefinition represents the sharable definition of the portlet and the PortletInstance represents a specific instance of that portlet being accessed by, or on behalf of, a specific user. The result of this split is that all APIs that affect an instance of a portlet (rendering, copying, security etc) have been brought together in the the PortletInstance class.
This change in architecture also allows developers more freedom because they are not forced to use the rendering, personalization and security frameworks provided by the PDK-Java. The base class, PortletInstance, exposes all the methods you need and provides some level implementation. A complete implementation that exposes all the familiar rendering, security and personalization frameworks of the PDK-Java is provided in DefaultPortletInstance.
Now we have cleanly defined classes that represent instances of a provider and portlet, all the API calls from the communication layer of the PDK-Java can be neatly funneled through the ProviderInstance and PortletInstance interfaces giving developers making the framework easier to understand for new developers.
Under the covers, the communications layer of the PDK-Java has also undergone some renovation. The changes that have been made in the communication layer are primarily in preparation for the migration of the provider framework to a web service using Oracle SOAP.
As a result of this preparatory work, you can now support multiple provider definitions running on the same servlet (in the same way that a single SOAP engine can support multiple web services). This deployment option is demonstrated in the PDK-Java samples which are all deployed on a single servlet.
ResourceRenderer is a new implementation of the ManagedRenderer interface that replaces the JspRenderer, Servlet20Renderer and, in most situations, FileRenderer. It lets you render any resource (JSP, Servlet, static HTML or static XML file) that is hosted on the provider's listener in a simple and consistent manner by specifying the relative URI to that resource.
ResourceRenderer is a managed renderer that works with the familiar RenderManager framework introduced in earlier releases of the JPDK.
The persistence mechanism used by the PDK-Java for portlet customizations has now been 'generalized' to allow persistence, retrieval and management of data scoped at almost any level. This new generic persistence mechanism is represented by the PreferenceStore class. It currently has two implementations: FilePreferenceStore a lightweight implementation that persists data on a file system, and DBPreferenceStore, an implementation that persists data in a relational database. Consequently, we now have a single 'general purpose' PortletPersonalizationManager implementation that uses a PreferenceStore to persist portlet customizations, PrefStorePersonalizationManager. For more information about using the PDK-Java Preference Store API, refer to the article How to use the Preference Store API.
Two new renderer classes, RPCWebServiceRenderer and DocWebServiceRenderer, have been provided to allow easy integration of web services into your portlets. For more information, refer to the article
The parameter passing model has been revised to allow portlets and portal pages to be "wired" together. In the new model, portlets declare their input parameters and also any events they raise. Events allow portlets to signal that the user has done something interesting. Each event may include a payload or set of values. A page designer can "wire" the payload of an event to the input parameters of other portlets on the same page or even another page through "page parameters". The new parameter passing model is described in several PDK articles.
Portal Authentication is a security feature that allows a web provider to authenticate the source of an HTTP request thereby protecting confidential data from prying eyes. This feature uses a system of shared keys and dynamically generated checksums to ensure that HTTP requests originate from a known and trusted source. Any requests that cannot be authenticated are rejected by the web provider.
OracleAS release 9.0.2 includes a component called Web Cache. Web Cache is an in-memory cache that sits in front of the Oracle HTTP Server and caches content delivered by the HTTP Server. Subsequent requests for the same content are served from the in-memory cache and the requests never even reach the HTTP Server. Content is cached using an invalidation model - that is, content is cached for a specified period, as in expiry based caching, but the application the owns the content can invalidate the cache entries at any time. The advantage of invalidation based caching is that you can cache dynamic content without needing to issue a "ping" request to determine if the content is still valid. Whenever anything happens in the owning application that would render the content invalid, the application issues an invalidation request to remove stale entries from the cache.
PDK-Java 9.0.2 v2 lets you use web cache in front of your web providers, caching portlet content so portlet requests are served from the in-memory cache. In addition, it also includes APIs that allow you to invalidate portlet content based on commonly used portlet and user information. You can also construct invalidation requests for application specific parameters.
For most developers, the impact of these changes is relatively small. The steps necessary to convert a provider from PDK-Java 3.0.9 to PDK-Java 9.0.2 are outlined in the article Migrating to PDK-Java 9.0.4
Follow the instructions within the Installing PDK-Java 9.0.4 article.
The following known issues exist in this release of PDK-Java:
Revision History: |
|
Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065, USA http://www.oracle.com/ |
Worldwide Inquiries: 1-800-ORACLE1 Fax 650.506.7200 |
Copyright and Corporate Info |