Jetspeed-2 Overview

Jetspeed-2

David Sean Taylor

Jetspeed-2 Enterprise Portals

Jetspeed-2

November, 2005 2

Portal Integration Framework

Jetspeed is an OPEN SOURCE application-integration portal framework. If you already know Spring, you can easily get started customizing your portal to your own needs. Jetspeed is entirely constructed with Spring components based on interfaces: the Jetspeed API. All aspects of the portal are configurable, including security, registries, preferences, and the core aggregation engine.

Portal Integration is about customization on a solid, open framework.

Customization of the portal framework is a matter of putting in your implementation at the correct integration point.

Customization of the user experience is accomplished with a flexible portal personalization engine, and with deployable units of markup.

All access to the portal must be secured.

Jetspeed-2

November, 2005 3

Jetspeed-2 Portal Framework Design Goals Standards and Specifications

– Fully Compliant with Java Portlet API Standard, pass TCK– WSRP-4J support (2.1)– Leverage Java Security, JAAS Security Components– LDAP

Open Source and Portability– Based on Open Source Libraries such as Jakarta Commons, Spring, OJB– Run on Open Source Application Servers

Component, Container Based Architecture – Integrators assembly components with Spring configurations– Light weight containers working on POJOs– Configurable Pipeline-based Request Processing

Scalability, Portability and Performance– Multi-threaded Portlet Aggregation Engine– Scalable Cluster Architecture (2.1)

Jetspeed-2

November, 2005 4

Framework Design Goals (continued)

Portal Framework – Separation of Portlet Applications from Portal– Live Deployment Model for Portlet Applications and Portal Layouts

Interface Driven Integration– Jetspeed API: component-based interface API– All parts of the portal can be wired together by Jetspeed API contract

Security– Authentication APIs– Authorization APIs– JAAS Policy Support– Security Constraints– SSO

Easy to Use, Customizable

Localization Ready

Jetspeed-2

November, 2005 5

Standards and Specifications

SpecificationsSpecifications – Jetspeed works with Java J2EE standards, Oasis, and WC3 standard specifications where applicable, most notably the Java Portlet API, along with providing its own specification essential for component interoperability.

The Portlet APIThe Portlet API – The Java Standard Portlet API is the specification dictating how Jetspeed runs portlets and portlet applications in the portal. It is the contract between portlets and the portlet container.

The Jetspeed Component APIThe Jetspeed Component API – Jetspeed provides a clear API for writing components that work inside the Jetspeed Component Portal Architectural. The Jetspeed Component API provides the contract between the portal and the component implementations.

WSRP (OASIS) – WSRP (OASIS) – not supported until 2.1+

JAAS Security – support Java Security policies, integrated support with Java Login Modules

Jetspeed-2

November, 2005 6

JSR 168: The Java Standard Portlet Spec

JSR168 is the Portlet specification enables interoperability between Portlets and Portals. The specification defines a set of APIs that addresses standardization of portlet aggregation, personalization, presentation and security. The current goals of JSR168 are to:

Define common Portal metaphor

Define a standard Portlet Java API

Ensure interoperability and portability

Enable multiple markups support

Ensure compatibility with other technologies \

The Jetspeed-2 Portlet Server supports the JSR 168 standard. This is an important initiative, introducing true portlet portability.

Jetspeed-2 has passed the TCK (Test Compatibility Kit) suite and pending full CERTIFICATION to the Java Portlet Standard.

Jetspeed-2

November, 2005 7

Software Architecture Design Concepts

Jetspeed is founded on the following core Software Architectural Design concepts:

Interface Driven Development – the Jetspeed API

Lightweight Containers and Component Oriented Programming based on the Spring Framework

Inversion of Control with Spring Containers

Aspect-Oriented programming

POJO Assembly and Dependency Injection

Pipeline Driven Processing

Aspect Oriented Programming

Separation of Concerns: Portal vs Portlet Applications Frameworks

100% Open, Standardized Open Source Solutions

Jetspeed-2

November, 2005 8

Jetspeed-2 Configurations

Jetspeed-2 is built entirely of components. With these components, the entire portal is assembled together at runtime. Jetspeed is built upon a set of portal components, allowing the application assembler to use the standard Jetspeed components, or plug-in their own components. Of course Jetspeed-2 comes with a default assembly out of the box. As Jetspeed-2 progresses, several implementations of components will be available.

For version 2.1, we are working two configurations :

1. Jetspeed Light – a light weight implementation of Jetspeed with no container managed security. One self-contained web application running in Jetty.

2. Jetspeed Enterprise – the full portal

Jetspeed-2

November, 2005 9

Component Programming

As of this writing, there is a revolution, or perhaps a reaction, to the heavy-weight complexities of the J2EE world. This revolution is going on right here in open source communities. The common trend is lightweight component frameworks for wiring together and managing components. Two marginally successful lightweight component frameworks are Pico Container and GBeans. The real success story is the Spring Framework. Interestingly, these component frameworks impose little or no requirements upon the components, meaning that POJO (Plain Old Java Objects) can be components. This lack of imposing framework requirements, is simple, yet leads to powerful portability possibilities. For example, the Pico and Spring frameworks are now available for Microsoft's .Net.

Jetspeed-2

November, 2005 10

Spring

Spring is also an open source project; however it is not housed at Apache. Spring is a unique Java application framework meant to simplify develop applications. Where as Enterprise Java Beans are very complex to use, the Spring Framework is an easy to use and understand framework for business applications. Spring focuses on:

1. Providing a simple way to manage Business objects lifetime and relationships

2. A layered architecture. Spring is comprehensive yet modular. You only use what you need. For example, you may only make use of the JDBC support without linking in an entire framework.

3. Promoting best software development practices. For example, Spring is designed to always promote test-driven development and eliminate the need for factories and singletons.

4. Inversion of Control. Spring is an application container supporting interceptions and declarative aspect oriented programming.

Jetspeed-2

November, 2005 11

Inversion of Control: Spring containers

The Inversion of Control pattern is based on the concept that a Component is always externally managed.. Every stage in the life of a component is controlled by the component container. This pattern provides a secure method for components to interact with the container. This design pattern addresses a component's dependency resolution, configuration and life cycle. The most significant aspect to IoC is dependency resolution and most of the discussion surrounding IoC dwells solely on that.

“Simply put, a component designed according to IoC does not go off and get other components that it needs in order to do its job. It instead declares these dependencies, and the container supplies them: thus the name IoC/DIP/Hollywood Principle. The control of the dependencies for a given component is inverted. It is no longer the component itself that establishes its own dependencies, but something on the outside. That something could be a container like Spring, but could easily be normal code instantiating the component in an embedded sense.” Paul Hammatt, PICO

Jetspeed-2

November, 2005 12

Jetspeed + Spring

Jetspeed currently works with one lightweight component container framework: Spring. The Jetspeed-2 team is also looking into running Jetspeed components inside of the Geronimo GBeans component framework. The importance is that both Geronimo and Spring are COP container frameworks, supporting component assembly, configuration, and component container features such as:

DecoratorsDecorators – or interceptors, for AOP-like chained method interception

Hot swappingHot swapping – allows implementation hiding and swapping

FailoverFailover – failover to next component when a component fails

MulticastingMulticasting – multicasting of method invocation to multiple components

Lifecycle managementLifecycle management – starting, pausing and resuming components

Jetspeed-2

November, 2005 13

Components run in a Spring Container

Jetspeed is a collection of components, all assembled together to create a complete working portal. If you look at from this point of view, you can see the major portal components being managed by the container, which is really just a Spring container:

Jetspeed-2

November, 2005 14

Jetspeed API

The Jetspeed APIThe Jetspeed API – Separation of Interface from Implementation

Jetspeed provides the interfaces to all portal components with the Jetspeed Portal API. The implementations are separated in the component modules. All components introduced to Jetspeed should become a part of the API, allowing for pluggable component implementations.

Components always have their dependencies constructor (or getter) injected via interfaces, not implementation references.

Jetspeed-2

November, 2005 15

Programming to the Jetspeed API

• Jetspeed Components always program to the Jetspeed API.• First, their dependencies upon other Jetspeed components are

always injected. Dependencies are declaratively managed in the Spring configuration. In Jetspeed, we support both constructor and setter dependency injection. Here is an example of a component having its dependencies constructor-injected:

Jetspeed-2

November, 2005 16

Dependency Injection (Constructor)

Constructor Dependency Injection is a type of dependency injection where a component receives all dependencies in the component's constructor. The benefits of Constructor Injection are:

1. It makes a strong dependency contract

2. It makes testing easy, since dependencies can be passed in as Mock Objects.

3. It's very succinct in terms of lines of code

4. Classes that rely on Constructor Injection are generally Good Citizens

A dependency may be made immutable by making the dependency reference final

Jetspeed-2

November, 2005 17

Wiring in XML to the Jetspeed API

The Spring configuration, wiring, or injecting, dependencies in XML constructor. Note that referenced beans are by Jetspeed API interface, not implementation.

Jetspeed-2

November, 2005 18

Pluggable Components and Jetspeed API

LDAP User Manager

RDBMS User Manager

Custom User Manager

Jetspeed API

User Manager

Role Manager

Component Implementations

Jetspeed-2

November, 2005 19

Component API Bus

Jetspeed API

User Manager

Statistics

Portlet Registry

Page Manager

SSO

Aggregator

Component Implementations

Jetspeed-2

November, 2005 20

Spring XML Component Construction<bean id="TemplateLocator" class="org.apache.jetspeed.locator.JetspeedTemplateLocator"

init-method="start" destroy-method="stop" >

<constructor-arg>

<list>

<value>${applicationRoot}/WEB-INF/templates</value>

</list>

…

• Id = the interface or component (bean) name

• Class = the implementation class

• Init-method = a method on the class called during container’s init phase

• Destroy-method = a method on the class called during container’s destroy phase

• list = Spring XML supports wiring standard Java collections and data types such as lists, maps, sets, properties

Jetspeed-2

November, 2005 21

Example of Injecting Dependencies

Example of Injecting Dependencies during Assembly of Component:



<bean id="org.apache.jetspeed.aggregator.AsyncPageAggregator"

class="org.apache.jetspeed.aggregator.impl.AsyncPageAggregatorImpl">

<constructor-arg index='0'>

<ref bean="org.apache.jetspeed.aggregator.PortletRenderer" />

</constructor-arg>

<constructor-arg index='1'>

<ref bean="org.apache.jetspeed.aggregator.ContentServerAdapter" />

</constructor-arg>

</bean>

Jetspeed-2

November, 2005 22

The Constructorpublic class AsyncPageAggregatorImpl implements PageAggregator

{

private final static Log log = LogFactory.getLog(AsyncPageAggregatorImpl.class);

private PortletRenderer renderer;

private ContentServerAdapter contentServer;

private List fallBackContentPathes;

public AsyncPageAggregatorImpl( PortletRenderer renderer,

ContentServerAdapter contentServer)

{

this.renderer = renderer;

this.contentServer = contentServer;

}

Jetspeed-2

November, 2005 23

Transactions and Interception

Interception begins and commits transaction:

grantPermissionUser Registration Portlet

PermissionManager

storeUser

SpringTXProxy

BEGINTX

JOINTX UserManager

COMMIT TX

Jetspeed-2

November, 2005 24

Declarative Transaction via Interception

Jetspeed-2

November, 2005 25

Failover and Recovery

Jetspeed-2

November, 2005 26

Jetspeed Components

All Jetspeed components are configured and wired together in a collection of XML files found under the Jetspeed web application directory: WEB-INF/assemblies. There are quite a few XML files there, as we like to break down the assembly of components by category, making it easier to override component assemblies by simply replacing the component-specific XML file.

Jetspeed runs with 2 Spring containers:

1. The boot container

2. The default container

The boot container holds all components that are required to be loaded before any other components. The data source component is loaded here.

Jetspeed-2

November, 2005 27

Spring Configurations Files

Jetspeed-2

November, 2005 28

The Jetspeed Engine

The Jetspeed Engine starts up the Jetspeed portal. We usually embed the engine inside of a servlet, giving us the standard MVC model. We have also embedded the Jetspeed Engine into several other open and closed source solutions including:

1. Jetspeed Fusion – running Jetspeed-2 engine inside of Jetspeed 1.6 giving 1.6 JSR-168 support via a Jetspeed-2 engine

2. Jahia Portal

The real job of the engine is to:

1. Create an integration point for embedding Jetspeed into other technologies

2. Provide entry point for pipeline-based processing

3. Abstract the concept of a Spring light weight container with the Component Manager

4. Provide basic lifecycle management of the Jetspeed portal

Jetspeed-2

November, 2005 29

Jetspeed Engine bootstrapThe Jetspeed Servlet is configured in the portal application web.xml to load at startup. The engine

bootstraps the Spring configuration.

engine = new JetspeedEngine(properties, applicationRoot, config, initializeComponentManager(config, applicationRoot, properties));

Jetspeed-2

November, 2005 30

Pipelines

Jetspeed-2 Pipelines are based on the inversion of control pattern. The request processing pipeline is assembled to run in the Spring container. A portal is largely driven by a request/response processing data flow, much like the servlet or HTTP request/response paradigm. Requests are made by client agents such as HTML or WAP browsers, and the portal processes the request on the thread provided by the application server for which Jetspeed is running. Request processing is achieved in a workflow like pipeline, where valves are plugged into the request pipeline. The workflow of the valves is configurable just like any other Spring component. Pipelines reference (via Spring constructor based dependency) one or more valves. Valves are also Spring components.

Jetspeed-2

November, 2005 31

Pipeline Driven Processing

Requests to the portal always come in via a Portal URL. Jetspeed has URI entry points. The servlet context (/jetspeed) is also easily configurable. Additionally, the request URL can be mapped to a portlet pipeline. The default pipeline aggregates portlet pages. Portlet pages are usually defined with the extension .PSML. If a page is not supplied, default pages can be configured.

Jetspeed Portal

Request to:/jetspeed/portal/home.psml/jetspeed/portal/home.psml

Page Pipeline

Portlet App #1

Portlet App #2

Portlet 1A

Portlet 2A

Portlet 2BPortlet1A

Client (browser)

Page

Dispatcher

Portlet2A

Portlet2B

Portlet 1B

Portlet1B

Jetspeed-2

November, 2005 32

Pipeline ArchitectureIn Jetspeed-2 request are processed through a series of Valve

assembled together as a pipeline.

Jetspeed-2

November, 2005 33

Jetspeed Render (Page) Pipeline

1. Render Pipeline - The default Jetspeed request pipeline. This pipeline processes the render phase as defined in the Portlet API specification. It does the typical aggregation of content rendered by each portlet.

Jetspeed-2

November, 2005 34

Action Pipeline

2. Action Pipeline – This pipeline processes the Action phase as defined in the Portlet API specification. Only one portlet may execute the action phase. All other portlet rendering threads are blocked during the action phase.

Jetspeed-2

November, 2005 35

Desktop Pipeline

2. Desktop Pipeline – This pipeline processes the Action or Render phase for the Jetspeed Desktop. The Jetspeed Desktop is a AJAX based, client-rendering (Java-script) implementation of a JSR-168 portal. Portlets are rendered individually, as opposed to a full page rendering engine such as the Page Pipeline. If you have n portlets on a page, during the initial rendering of a desktop page, n desktop pipeline requests will be made. However, if you go to render just one portlet, other portlets will not be rendered unless their cache has expired. For actions, all one action request is made, and then n render requests are made for each portlet on the desktop.

This leads to a more distributed rendering engine. However, it may put higher load on your network.

Jetspeed-2

November, 2005 36

Portlet Pipeline

3. Portlet Pipeline – This pipeline is used to render the contents of a single portlet. This pipeline is used by several portal vendors to embed JSR-168 support in their portal via Jetspeed-2 technology. It is the foundation for the Desktop pipeline. The portlet pipeline is also embedded in Jetspeed 1.6 (Fusion) to give JSR168 support to Jetspeed 1.6 portals.

Jetspeed-2

November, 2005 37

AJAX Pipeline

The AJAX Pipeline processes AJAX requests. We are developing an AJAX XML API for Jetspeed-2, to process requests for AJAX customizers such as portlet layouts and portlet placement. (Note that security should be enabled) The AJAX pipeline hooks into an AJAX service, which can then delegate to AJAX actions. These action build XML response packets (with Velocity and Java Beans) which are sent back to the AJAX client.

Jetspeed-2

November, 2005 38

File Server Pipeline

Retrieves requests for a particular file, using portal security. Requests can be mapped here for non-PSML file types automatically such as /jetspeed/portal/content/story.html

Jetspeed-2

November, 2005 39

Pipeline Mappings

Pipelines mappings allow for prefixed mappings of /context path + servlet path to be mapped to a pipeline. For example:

/jetspeed/portal --> Jetspeed Pipeline

/jetspeed/ajax --> Ajax Pipeline

/jetspeed/portlet --> Portlet Pipeline

/jetspeed/fileserver/file.pdf --> File Servlet Pipeline

/jetspeed/fileserver.file.html --> File Servlet Pipeline

/jetspeed/desktop - Desktop Pipeline

Jetspeed-2

November, 2005 40

Pipeline Mapping Configuration

Jetspeed-2

November, 2005 41

Pipeline Examples

• /jetspeed/portal /jetspeed/desktop

Jetspeed-2

November, 2005 42

Pipeline Examples (continued)

• /jetspeed/portlet

Jetspeed-2

November, 2005 43

Valves and the Request Context

Valves are units of work along the pipeline workflow. Typically valves represent access to a Jetspeed feature or component, such as aggregation, security, action processing, or device capabilities.

The Jetspeed Pipeline has a request context associated with the entire request pipeline. Using the Request Context API, valves can add or retrieve bits of information to the pipeline request process.

ProfilerValve

RequestContext

Set PageAggregator

Valve

Get Page

Jetspeed-2

November, 2005 44

Pipeline Valves

Identifies the Capability Map, character encoding, media and Mime types for the browser to the Request Context, sets the content type in the response.

CapabilitiesValve

Creates the internal Portal URL from the request URL and parameters using the Navigational State component

Portal URLValve

Builds the Java Security subject for the request, and runs all remaining valves for this request under a privileged action, enabling Java Security checks against the default Jetspeed (JAAS) security policy, or, if configured, another standard JAAS policy.

Security Valve

Sets the Locale (java.util.Locale) into the request context for Java standard internationalization support

LocalizationValve

Jetspeed-2

November, 2005 45

Pipeline Valves (continued)

Uses the Profiler, Site Manager, and Page Manager components to locate the requested page and menu ‘site’ navigations Profiler

Valve

Determines the targeted action window in the request, if found, executes the action via the portlet container. This is the standard “action phase”, blocking all rendering. At completion of the action phase, the action valve redirects back to the portal to process the render phase.

ActionValve

Builds the actions available on the page and all portlet windows

DecoratorValve

Executes the standard “render phase”, where the actual rendering of all portlets and page decorations occurs.

AggregatorValve

Jetspeed-2

November, 2005 46

Pipeline Valves (Desktop)

Renders the skeleton of the Jetspeed Desktop. All desktop portlet rendering is controlled on the client side, with javascript and the portlet pipeline

DesktopValve

Executes Jetspeed Desktop actions over the span of one request. The client-side desktop controls the execution of the action phase, and then the subsequent render phases, achieving parallel processing from the client-side.

Desktop ActionValve

Jetspeed-2

November, 2005 47

Jetspeed Components: Core Engine

Engine The Jetspeed Engine (not configured in Spring. The Jetspeed bootstrap servlet adds the engine to the Spring container)

PortletWindowAccessor Handles all access to portlet windows. Portlet windows are temporary objects representing a portlet and its preferences for a particular window or fragment

Pluto The Pluto portlet container

DesktopPluto The Pluto portlet container for the desktop (requires different action handling)

PortletContainer Wrapper around Pluto Container to enable Spring configuration of Pluto

DesktopPortletContainer

Wrapper around Pluto Container to enable Spring configuration of Pluto

Jetspeed-2

November, 2005 48


portal_configuration Wire in global properties configuration from a file

javax.servlet.ServletConfig

Wire in the Servlet configuration from the Jetspeed servlet webapp

TemplateLocator Handles algorithms for locating language, country, media-type specific Jetspeed web application templates (JSP, Velocity)

DecorationLocator Handles algorithms for locating language, country, media-type specific decorations

Powertools The Jetspeed Power Tool factory

IdGenerator Generates Unique Ids for pages and fragment

Page File Cache Handles caching of PSML files

Jetspeed-2

November, 2005 49


RequestContextComponent

Request Context Factory

HeaderResourceFactory Allows components to participate in the creation of the <HEAD> markup, supplying scripts and CSS into the header area. (NOTE: a header phase will be added to the Portlet API 2.0 spec)

ProductionConfiguration

Alternative property configuration for production systems

Jetspeed-2

November, 2005 50

Administration

PortalAdministration Provides general purpose portal administration functions:

• Send emails

• Find a user given an email

• Register New Users

mailSender Spring email component

adminVelocityEngine Velocity engine for merging emails

Jetspeed-2

November, 2005 51

Aggregation

PortletAggregator Handles aggregation processing of single portlet requests from the portlet pipeline

PortletRenderer Renders single portlets from all pipelines

PageAggregator Handles the “render phase” of the Portlet API, aggregating content of all portlets and decorations on a page

Jetspeed-2

November, 2005 52

Ajax Actions

AjaxMove* AjaxGetMenus

AjaxAddPortlet AjaxGetMenu

AjaxRemovePortlet AjaxRequestService

AjaxGetPortletsList is growing, under development

AjaxGetPage

AjaxGetPages

AjaxChangeWindow

Jetspeed-2

November, 2005 53

Jetspeed AJAX XML API

The Jetspeed XML AJAX APIThe Jetspeed XML AJAX API – an XML-based API for AJAX clients to make asynchronous requests to Jetspeed-2 services. Typical usage:

Page Customization and Portlet Placement (move/add/remove Portlet)

Layout Selection (change layout for a page)

Decorations – select decorators for a portlet or page

Portlet Selectors

Security Configuration for a Portlet or Page

Menu Configuration

Page Ordering in a Folder

Jetspeed-2

November, 2005 54

AJAX APIs and Security

AJAX APIs are secured just like any other portal request. The security is the same Jetspeed security as used to protect your portal. For example, requests for page content use the same page security constraints as would be applied to rendering a page. Likewise for portlet security permissions.

Jetspeed-2

November, 2005 55

Capabilities

Jetspeed-2 capabilities provides a mechanism for mapping the client used to access Jetspeed-2 to media types for page rendering.

The Jetspeed-2 capability engine maps clients to media types to mime types. Here are some more detailed definitions:

Clients: The application that initiates a request to the Jetspeed-2 portal engine. Jetspeed-2 uses the User-Agent to determine the client that initiates a request.

Media Type: The type of media requesting the content (HTML, WML, etc.). Content in Jetspeed-2 can be requested by different type of devices through different media.

Mime Type: The type of content being requested.

Supported Media Types: HTML, XHTML-BASIC, XML, WML, VXML

Jetspeed-2

November, 2005 56

Deployment

Deploying custom portlets in Jetspeed-2 is simple. Portlets are very similar to servlets. They require a deployment descriptor, portlet.xml which goes in WEB-INF and need to be packaged in a war-like format. In order to deploy a portlet, Jetspeed-2 requires the user to follow those steps:

1. Build your portlets as a portlet application just as you would a web application.

2. Package your portlet application into a .war file.

3. Copy the .war file to Jetspeed's deployment directory, by default this is WEB-INF/deploy. Jetspeed will take care of automatically deploying the portlet application into the application server, and then registering the portlets into the portlet registry.

You can also copy over a portlet-application’s web.xml or portlet.xml to cause re-registration of the portlet application.

Jetspeed-2

November, 2005 57

Deployment (continued)• The Deployment Manager is configured with the properties specified

in WEB-INF/conf/jetspeed.properties (this should probably change)• autodeployment.staging.dir: The directory scanned for autodeployment. • autodeployment.delay: The frequency of the deploy directory scanning.

Jetspeed-2

November, 2005 58

Deployment (continued)• The DeploymentManager is also configured with 2 types of listeners:

– The DeployPortletAppEventListener handles the hot deployment of portlet applications.

– The DeployDecoratorEventListener: handles the hot deployment of decorators.

Jetspeed-2

November, 2005 59

Portlet Application Management

ApplicationServerManager

Currently only Tomcat 5.5.x and 5.0.x supported. (Working on Jetty support.) Provides hooks into the application server to help us deploy portlet applications as web application into that server.

PortletApplicationManager (PAM)

Handles lifecycle of portlet application, including registration:

• startPortletApplication

• stopPortletApplication

• registerPortletApplication

• unregisterPortletApplication

Jetspeed-2

November, 2005 60

Other Application Servers and the Deploy Tool

Websphere, JBoss, Weblogic requires App-server specific deployment. With Websphere for example, we have to package up the portlet applications into an EAR file, which takes specific deployment tools for Websphere (or using the Websphere administrative UI).

Since the portlet applications are not deployed into the Jetspeed Deployment Manager, instead we must infuse registration code into the portlet application before it is packaged and deployed to Websphere. Jetspeed provides a Deploy Tool to run during the build process of your portlet application:

java -jar jetspeed-deploy-tools-<version>.jar -s inputWarPath outputWarPath

where:

-s: flag indicating whether or not to strip to loggers from the application. When the flag is present, the loggers available in the application will be removed.

inputWarPath: the path of the war to process.

outputWarPath: the path of the processed war.

Jetspeed-2

November, 2005 61

Deploy Tool changes to web.xml

The deploy tool adds the following servlet to your portlet application. This servlet allows Jetspeed to communicate with your portlet application to invoke cross-context portlet phases (action, render).

Additionally, the deploy tool instructs the servlet to attempt to register this portlet application during the servlet initialization phase. A check-sum value on the portlet.xml, web.xml, and jetspeed-portlet.xml for changes, determining if re-registration is necessary.

Jetspeed-2

November, 2005 62

Deployable Applications

The Portal and Portlet Applications are implemented as separate web applications. Jetspeed runs as a MVC-Controller-type servlet, running in a standalone web(portlet) application. Each portlet application runs in its own web application. The Portal then dispatches to portlets using cross-context invocation

Application Server

Jetspeed Portal Portlet App #1

PA WAR #1

PA WAR #2

Portlet App #2Portlet Registry

Deploy

Deploy

Register->

Register->

Jetspeed ClusterClustered App Servers

[JSR-88 J2EE Deployment]

Jetspeed-2

November, 2005 63

Jetspeed and Cross Context Concerns

The Portlet API strongly suggests that all portlet applications are each stored in different web applications. This means that parts of Jetspeed must exist in common class loaders shared amongst all web applications in the application server.

Tomcat Application Server

Shared Lib:

• Jetspeed-API jar• Pluto JAR• Jetspeed Commons• Bridges Commons

Jetspeed Webapp

* Jetspeed Implementation

Portlet Application #1

Portlet Application #1

PA #1Class Loader

PA #2Class Loader

Jetspeed-2

November, 2005 64

Local Portlet Applications

Local Portlet Applications are deployed directly into the Jetspeed web application and class and jar files are stored under the WEB-INF/apps directory. Resource files, such as HTML, CSS, images and JSP, must be stored in Jetspeed’s web application directory structure. The downside is that collisions of resource files from different web applications is possible. Class loader concerns are handled by Jetspeed correctly.

Advantages of this approach:

‘Jetspeed Lite’ solutions: deploy Jetspeed in one simple WAR file.

As of 2.0 and 2.1-dev, only Jetspeed layouts are deployed locally.

Jetspeed-2

November, 2005 65

PlutoPluto is the Reference Implementation of the Java Portlet

Specification. The current version of this Portlet specification is 1.0. Portlets are designed to run in the context of a portal. They are written to the Portlet API. Pluto implements the contract, the Portlet API, between portlets and portals. Pluto is a portlet container. Jetspeed embeds Pluto into the Jetspeed portal. Pluto is the default Container component in the Spring assembly, it is just another component.

Jetspeed-2

November, 2005 66

Pluto API: Portal to Portlet-Container Interface

The Pluto API is currently a set of not-so-well documented interfaces in Pluto. These interfaces can be categorized into the following groups:

1. Container Invoker APIs - provides ability to render portlets and perform actions on portlets.

2. Container Services APIs - provides a way to enhance the portlet container with services implemented in the portal.

3. Common Object Model APIs - provides a common object model to the Portlet API model defined by the portlet specification's deployment descriptor, and used by Pluto and Jetspeed as a common object model to share portlet applications, portlet descriptions, and portlet entity information between the portal, container, and the portal's persistent registry.

4. Factory APIs - Allows the entire container implementation to be plugged in and implemented by the portal, or default to the Pluto implementations

The goal is for Jetspeed and Pluto, through the open source community, to pave the way for a standardized portal to portlet container API.

Jetspeed-2

November, 2005 67

Pluto Spring-ized

LocalPortletInvokerFactory ServletPortletInvokerFactory

javax.portlet.ActionRequest javax.portlet.RenderRequest

javax.portlet.RenderResponse javax.portlet.PortletSession

javax.portlet.PortletConfig javax.portlet.PortletContext

javax.portlet.PortalContext javax.portlet.ActionResponse

javax.portlet.PortletURL javax.portlet.PortletPreferences

org.apache.pluto.invoker.PortletInvoker org.apache.pluto.util.NamespaceMapper

StaticInformationProvider InformationProviderService

ServletRequestFactor ServletResponseFactory

LogService DynamicTitle Service

Jetspeed-2

November, 2005 68

Navigational State

Navigational state holds:

• All portlet Request Parameters for all portlets

• Windows states for all portlets on the current page

• Portlet Modes for all portlets on the current page

Jetspeed supports several algorithms for encoding Nav state:

• PathNavigationalState: All fully encoded on URL:

• SessionNavigationalState: Only portlet window state (window state and portlet mode) are saved in the session, parameters are encoded on the url

• SessionFullNavigationalState: State and parameters are saved in the session (the default)

See portal-url-generation.xml for full Spring configuration

Jetspeed-2

November, 2005 69

Transitional Navigational State

Transitional navigational state can be seen encoded on the URL. Here is an example:

http://localhost:8080/jetspeed/portal/_ns:YWRwLTd8YzB8ZDB8Zg__/

Jetspeed-2

November, 2005 70

Portlet Preferences Component

Portlet Preferences are a feature of the Portlet API for providing a custom view or behavior of portlets for different users. The configuration is represented as a persistent set of name-value pairs. Jetspeed handles are persistence and retrieval of portlet preferences. The Jetspeed Preferences component stores its preferences in a relational database. All Jetspeed database access is done through Spring + OJB.

Programming with portlet preferences will be covered in the section on the Portlet API (JSR-168).

Jetspeed-2

November, 2005 71

Java Preferences APIThe Java Preferences API (java.util.prefs) provides a generic mechanism for

storing user and system preferences, as well as configuration data. Jetspeed 2 relies on this API to provide a wide ranging of functionality to higher level services. Some of the Jetspeed components leveraging the Preferences API are:

1. Portlet Preferences: Portlet preferences are stored in the system preferences tree. The following path structure is used to establish the location of a given portlet preference in the preferences tree:

/portlet_application/${PortletAppName}/portlets/${PortletName}/preferences/${Pref Name}/values

The preferences values are stored under the values node as a map of key/values.

2. User Attributes: User attributes are stored in the user preferences tree as follows. The following path structure is used to stored a user's attributes:

/user/${User Name}/userinfo

The user attributes are stored as a preferences key/values map under the userinfo node.

3. Roles and groups hierarchy

Jetspeed-2

November, 2005 72

Preferences Database

• All Preferences are stored in the following two database tables:

Jetspeed-2

November, 2005 73

Preferences in Edit Mode

Jetspeed-2

November, 2005 74

Portlet Registry

The Portlet Registry persists the entire contents of the portlet deployment descriptors in the Jetspeed database:

1. portlet.xml

2. jetspeed-portlet.xml (Jetspeed-specific extensions)

When a portlet application is deployed, Jetspeed updates the registry with the definitions defined in these portlet descriptors including:

1. One Portlet Application definition

2. One or more portlet definitions

3. Supported User Attributes

4. Supported custom portlet modes and window states

Details of the portlet.xml will be covered in more detail in the section on JSR-168 (Portlet API).

Jetspeed-2

November, 2005 75

Portlet.xml

• Portlet Name, description, display name

• Implementing class

• Init Parameters

• Supported Mime Types / Modes

• Supported Locales

• Resource Bundle Information / Localization (titles, keywords)

• Default Portlet Preferences

Jetspeed-2

November, 2005 76

Jetspeed-Portlet.xml

• We allow for extended metadata to attribute portlets and portlet applications. This metadata conforms to the "Dublin Core" DCMI format: http://dublincore.org/

• DCMI allows for extended metadata such as subject, contributor, language, publisher, relation, …)

• Map user attribute names to other attribute names

• Define Jetspeed Services used by this portlet.

Jetspeed-2

November, 2005 77

Jetspeed Services

• Jetspeed provides a way for portlets to access Jetspeed components, or services, from a portlet. Although this is a Jetspeed-specific feature, it is how Jetspeed Administrative portlets can work with customizing Jetspeed. For example, the Group Administration portlet below uses a Jetspeed service to manipulate Jetspeed groups.

• All services must be exported by Jetspeed in the jetspeed-services.xml file. All services required by a portlet must be specified in the jetspeed-portlet.xml

Jetspeed-2

November, 2005 78

Jetspeed Services defined in Spring

Jetspeed-2

November, 2005 79

Jetspeed Services (cont.)

Portlet applications requiring a jetspeed service must define it in their jetspeed-portlet.xml deployment descriptor:

<js:services>

<js:service name='ApplicationServerManager'/>

<js:service name='PageManager'/>

<js:service name='PermissionManager'/>

<js:service name='PortalAdministration'/>

<js:service name='UserManager'/>

</js:services>

Jetspeed-2

November, 2005 80

Jetspeed Services

And then get the service in the portlet init phase:

groupManager = (GroupManager)

getPortletContext().getAttribute(

CommonPortletServices.

CPS_GROUP_MANAGER_COMPONENT);

Jetspeed-2

November, 2005 81

Managing the Registry

• Jetspeed provides two portlets for managing the Portlet Registry:1. Portlet Application Browser

2. Portlet Application Details

Jetspeed-2

November, 2005 82

Managing the Registry, Details

Jetspeed-2

November, 2005 83

Search Component

• Jetspeed-2 provides an integration with the popular Apache Lucene search engine, a high-performance, full-featured text search engine library written entirely in Java; a technology suitable for nearly any application that requires full-text search, especially cross-platform..

• By default, Jetspeed-2 indexes all registry information: portlet instances and portlet definitions as searchable entities.

Jetspeed-2

November, 2005 84

User Information (Attributes)

• The Portlet API defines an interface for providing user information to portlets. Portlets can access this user information via the portlet API:

• User information can be edited with the User Manager portlet

Map userInfo(Map)

request.getAttribute(PortletRequest.USER_INFO);

String givenName = (String)userInfo.get("user.name.given");

String email =

(String)userInfo.get("user.home-info.online.email") ;

Jetspeed-2

November, 2005 85

Profiler

• The Jetspeed Profiler is a portal resource location rule-based engine. The profiler locates the following kinds of portal resources:

• PSML pages • Folders • Menus • When a request is received by the portal, the profiler will map the

request to a resource based on a normalized set of runtime parameters and state such as request parameters, HTTP headers, and session attributes. The Profiler is invoked during the Jetspeed request processing pipeline in the profiler valve. This valve requires that the request context is already populated with the portal request and response, capabilities, language and user information. The runtime parameters make up the profile criterion which the profiler uses to locate portal resources. The profiler works hand in hand with the Site and Page Manager components.

Jetspeed-2

November, 2005 86

Profiler Rules and Rule Criteria

A Profiling Rule defines a list of criteria used when evaluating a request to determine the location of a specific resource. Profiling rules are used by the profiler to generically locate portal resources based on the decoupled criteria for known portlet request data. A rule consists of an ordered list of criteria which should be applied in a given order. Following this rule's order, the profiling engine applies each criteria of the rules using a less-specific algorithm until the least specific resource criterion is considered. When all criteria are exhausted, the rule will fail and a fallback resource will be required.

Rule Criteria are templates for locating profile properties. Jetspeed has a profiling policy based on resource-specific URLs, Mime-Types and language preferences. More complex implementations will need to use other inputs in mapping to resources such as Cookies, IP Address Ranges, Statistical Resource Usage Analysis, Business Rules inside of servlets or EJBs,...

Jetspeed-2

November, 2005 87

Rule Criterion Resolvers

• Resolvers are Java classes that try to match criteria to find resources

Jetspeed-2

November, 2005 88

Directories of PSML Pages

The Profiler searches over a directory tree of PSML pages trying to locate a PSML page to be displayed. By default, this directory structure is found under WEB-INF/pages. The ‘directory’ can also be stored in the database. There are several system directories known by the profiler:

1. _user – holds all user-specific pages

2. _role – holds all role-specific pages

3. _group –holds all group-specific pages

4. __subsite-root – contains complete subsite trees, exactly like root tree

Jetspeed-2

November, 2005 89

Common Profiler Rules Provided• J1 – uses a most-specific to least-specific algorithm from Jetspeed-

1• Page-Path + User + Media Type + Language + Country

• J2 – Default. Looks at the URL path combined with User + Media• Page-Path + User + Media Type

• Role Fallback - Look for page in each role dir for the given user• User-Role Fallback – Look for page in user’s home dir, if not found,

look in each role dir for the given user• Variants: Path, Group Fallback, User-Role-Combo Fallback,

Subsite-Roll Fallback

Jetspeed-2

November, 2005 90

A Path-MediaType Role Fallback Example

Path

ProfilerMedia Type Page

Role FallbackRepeat over each role for user

Jetspeed-2

November, 2005 91

Profiler Rule Example

Path: /my-page.psml

ProfilerRoles: Admin, Tester

/roles/admin/html/my-page.psml

Media: HTML, XHTML

Page Manager

Profile Locator

Jetspeed-2

November, 2005 92

Page Manager

The Page Manager persists and secures access to pages. Pages are the basic resource for storing one or more portlets for viewing.

By default, pages are stored on the file system in the web application under WEB-INF/pages. This location should be moved in production systems. See page-manager.xml for changing this configuration. The File System Page Manager will scan for new PSML every 10 seconds (configurable)

There is a second Page Manager implementation, the Database Page Manager. This alternate Page Manager stores all data in a relational database. To use the Database Page Manager:

1. Run the database importer to import PSML into the database

2. Swap the assembly/alternate/db-page-manager.xml with the file system version

NOTE: you can also export out from the database to the file system.

Jetspeed-2

November, 2005 93

Security and the Page Managers

The Page Managers support two kinds of security:

1. Permission Security (Java Security Policy)

2. Constraints Security (PSML Constraints)

In the page manager’s Spring configuration, you can enable either one of these, or turn them both off (not recommended)

Example Security Constraint:

<security-constraints-def name="manager">

<security-constraint>

<roles>manager</roles>

<permissions>view</permissions>

</security-constraint>

</security-constraints-def>

Jetspeed-2

November, 2005 94

Jetspeed Database

The Jetspeed Database is configured in Spring under :

WEB-INF/assembly/boot/datasource.xml

By default, we use Spring to configure a JNDI data source. This data source needs to be configured on your application server.

<bean id="JetspeedDS" class="org.springframework.jndi.JndiObjectFactoryBean">

<property name="resourceRef"><value>false</value></property>

<property name="jndiName">

<value>java:comp/env/jdbc/jetspeed</value>

</property>

</bean>

Jetspeed-2

November, 2005 95

Tomcat’s JNDI JDBC Configuration

• Jetspeed creates a Tomcat context file for the Jetspeed web application and deploys it to Tomcat automatically. This context file holds the JDBC configuration for the database used by Jetspeed internally. Note in our example below, we have renamed the default Jetspeed context to “/fep”. The Jetspeed custom build automatically handles context renaming.

Jetspeed-2

November, 2005 96

OJB

• OJB, the Object Relational Bridge, is an object-relational mapping tool from the Apache Software Foundation. All database access in Jetspeed runs thru OJB. Mapping is controlled with a simple XML mapping file, which tells OJB how to map from database tables to Java classes. Each component in the system has its own OJB mapping file. It can be found in the component’s jar under the JETSPEED-INF directory. Here is an example mapping:

Jetspeed-2

November, 2005 97

OJB Support

• OJB supports the most popular open source and proprietary databases. OJB will automatically figure out which database is in use by looking at the JDBC data sources metadata.

• OJB is a powerful object-relational tool supporting associations such as one to many, and mapping those associations to Java Collections. You can also set associations to be auto-retrieved or lazy-loaded.

Jetspeed-2

November, 2005 98

Supported Database and Torque

The Torque project is another database project from Apache. It is used to generate database specific schema for your portal. This is done by simply setting a property, and then using the Jetspeed custom build to build your custom portal with proper database support. By default, Jetspeed now uses the Derby database. Although OJB and Torque support more database, the list of supported and tested databases with Jetspeed are:

1. Oracle

2. MySQL

3. Microsoft SQL

4. PostgreSQL

5. DB2

6. Hypersonic

7. Derby

Jetspeed-2

November, 2005 99

XML Torque files

Torque uses XML files to generically define the database definitions (DDL), table and indexes:

<table name='PORTLET_STATISTICS'>

<column name='IPADDRESS' type='VARCHAR' size="80"/>

<column name='USER_NAME' type='VARCHAR' size="80"/>

<column name='TIME_STAMP' type='TIMESTAMP'/>

<column name='PAGE' type='VARCHAR' size="80"/>

<column name='PORTLET' type='VARCHAR' size="255"/>

<column name='STATUS' type='INTEGER'/>

<column name='ELAPSED_TIME' type='INTEGER'/>

</table>

Jetspeed-2

November, 2005 100

Database Population Scripts

The database population scripts are still specific for each supported database. Because of the non-standard-ness of the SQL standard, we need to have different seed population scripts for each database flavor. A lot of the population scripts that come with Jetspeed out of the box may not be applicable in your portal, such as the default roles and groups and administrative users.

We hope to phase out SQL population scripts in version 2.1

Jetspeed-2

November, 2005 101

Jetspeed XML

Jetspeed XML and the Jetspeed Serializer component will phase out database population scripts. Jetspeed XML is an XML format for importing and exporting Jetspeed data such as:

• Users

• User Information

• Roles

• Groups

• Profiling Rules and Criterion

• Permissions

Note: Jetspeed serialization is still under development at this time

Jetspeed-2

November, 2005 102

Websphere configuration

Websphere requires a special configuration:

WEB-INF/assembly/wps.xml

<beans>



</beans>

The Portal Request Factory is replaced with Websphere because of the way that Websphere 5.x derives the context path during cross-context requests to render portlets.

Jetspeed-2

November, 2005 103

Jetspeed Security

Jetspeed 2 security leverages J2EE authentication and authorization standards for both authentication and authorization through the implementation of a default Login Module and a default Authorization Policy.

Authentication establishes the identity of the user and populates the Subject with all the user principals. In a portal context, the populated Subject is added to the session in the Security Valve implementation. The Subject principals are then used to authorize the user's access to a given resource. Jetspeed Security leverages JAAS authorization by checking the user's permission with the Java Access Controller.

The Authorization policy is a standard Java Security Policy. The Jetspeed implementation of this policy a RDBMS policy, stored in the Jetspeed database.

Jetspeed-2

November, 2005 104

Jetspeed Security Layers

• Jetspeed Security can be accessed at the Java API layer: the JAAS API

• We implement both a Login Module and Security Policy

• Jetspeed Security Managers are configured in security-managers.xml

Security managers are high-level APIs, used to manage users, roles, groups and permissions

Jetspeed provides a Security Service Provider Interface (SPI) for layered handlers of security services. See the security-providers.xml and security-spi-*.xml

Jetspeed-2

November, 2005 105

JAAS Login Module Configuration

Jetspeed security architecture is fully JAAS compliant. Integrators can replace Jetspeed security architecture with their own LoginModule and Policy implementation.

To configure the login module, edit security-atn.xml. The Login Module proxy bootstraps the Login Module into the Spring initialization life cycle. You can disable Jetspeed’s login module by removing this file in your deployment.

<bean id="org.apache.jetspeed.security.LoginModuleProxy"

class="org.apache.jetspeed.security.impl.LoginModuleProxyImpl" >

<constructor-arg index="0">

<ref bean="org.apache.jetspeed.security.UserManager"/></constructor-arg>



<constructor-arg index="1"><value>portal-user</value></constructor-arg>

</bean>

Jetspeed-2

November, 2005 106

JAAS Security Policy Configuration

The JAAS Security policy is implemented as a RDBMS security policy. It bootstraps during the Spring initialization life cycle. You can disable Jetspeed’s security policy by removing this file in your deployment.



<bean id="org.apache.jetspeed.security.impl.RdbmsPolicy"

class="org.apache.jetspeed.security.impl.RdbmsPolicy" >

<constructor-arg >

<ref bean="org.apache.jetspeed.security.PermissionManager"/></constructor-arg>

</bean>

Jetspeed-2

November, 2005 107

Permission ManagerSecurity Permissions in Jetspeed are standard Java permissions. We support 3 kinds of

permissions:• 1. Portlet Permission• 2. Folder Permission• 3. Page PermissionPermissions are stored in the RDBMS Security Policy. They protect resources for given

actions. Permissions are RBAC (Role-based Access Controls) applied to portlet actions (view, edit, help, configure)

AccessController.checkPermission(new PortletPermission(portlet.getUniqueName(), JetspeedActions.MASK_VIEW));

Jetspeed-2

November, 2005 108

Permission Manager impl

Jetspeed-2

November, 2005 109

User, Role and Group ManagersJetspeed provides its own User management out of the box. Many deployed systems replace

the user management with their own database, or LDAP implementations. Role and Group managers are also provided out of the box along with administrative tools.

Jetspeed-2

November, 2005 110

Login Module

For authentication, Jetspeed 2 provide a default login module implementation. Login modules provide a standard way to expose authentication services for java application.

Configuration is central to JAAS authentication. By default, Jetspeed 2 is configured to use its DefaultLoginModule implementation. The configuration file (login.conf) for the login module ship with the jetspeed2-security-{version}.jar component and provide the following configuration:

Jetspeed { org.apache.jetspeed.security.impl.DefaultLoginModule required; };

In order to override this configuration, you can place your own login.conf file in your web application class path under WEB-INF/classes. The location of the login.conf file is configured in the security-providers.xml file.

Jetspeed-2

November, 2005 111

Login Module + User Manager

• The login module leverages the User Manager to authenticate users

Jetspeed-2

November, 2005 112

Authentication SPI

• Authentication service providers are configured in security-spi-atn.xml file. Here the user management handler is configured as well credentials handlers

Jetspeed-2

November, 2005 113

Credentials

Jetspeed provides quite a few features for managing credentials:

1. A custom password credential implementation

2. Configurable Password Encoding with standard SHA-1 or Base-64

3. Enforced Password Value Rules (not blank, minimum length, minimum numeric characters)

4. Interception framework for handling credential life cycle events:1. Validate Password on login load and force change if invalid

2. Encode Password on first load

3. Password Expiration enforces lifespan for passwords managing expiration date

4. Max Password Failures enforces maximum number of invalid password attempts in a row

5. Password History forces unique passwords in respect to previously used passwords

Jetspeed-2

November, 2005 114

Credentials Implementation

Jetspeed-2

November, 2005 115

Login Validation• The Login Validation Valve provides feedback to the user about the cause of an failed login

attempt.• It retrieves the User Principal and its current Password Credential for the specified user name, and

(if found) determines an specific error code based on its state. This error code is communicated back to through the session so an appropriate error message can be presented to the user.

• The following possible error codes can be returned :• ERROR_UNKNOWN_USER • ERROR_INVALID_PASSWORD • ERROR_USER_DISABLED • ERROR_FINAL_LOGIN_ATTEMPT • ERROR_CREDENTIAL_DISABLED • ERROR_CREDENTIAL_EXPIRED

• Of the above error codes, the ERROR_FINAL_LOGIN_ATTEMPT will only be reported if the valve is configured with the same maxNumberOfAuthenticationFailures value as used for the related MaxPasswordAuthenticationFailuresInterceptor described above:

Jetspeed-2

November, 2005 116

Managing Password Expiration

• If the PasswordExpirationInterceptor is used, password expiration for a certain user can be directly managed through the UserDetailPortlet provided with the security portlet application.

• If enabled, this portlet can display the current expiration date of a password and also allows to change its value:

Jetspeed-2

November, 2005 117

Single Sign on

• Jetspeed-2 Single Sign-on (SSO) feature is a credential store implemented as a component. It uses J2 security implementation for storing credentials. A management portlet allows the editing of SSO sites and remote credentials. It supports Basic Authentication and Form Based authentication and supports cookies.

• The SSO Management administrative feature enables you to configure "single sign-on" access interactively.

Jetspeed-2

November, 2005 118

SSO Administration Portlet

Jetspeed-2

November, 2005 119

Web Content Portlet + SSO• Jetspeed comes with a sample Web Content Portlet that uses SSO.• Enter the following credentials on the setup screen:• username = jetspeed_test0

password = jetspeed

Jetspeed-2

November, 2005 120

Web Content Portlet + SSO (continued)• Once the credentials are entered,

you will no longer need to enter them for this user. The user will be automatically logged on to the NY Times site

• Credentials can be configured for a group of users as well as a single user in the SSO admin

Jetspeed-2

November, 2005 121

Portlet Statistics• Jetspeed gathers statistics about portlet activity and logs it to either a database or a CLF file.

The portlet can gather statistics over time periods as well as the top hit portlets. Of course you can use your own tools or queries to gather this information from the database. Statistics for portlets display hit counts and render times in milliseconds

Jetspeed-2

November, 2005 122

User Statistics

• Jetspeed gathers statistics about user activity and logs it to either a database or a CLF file. Statistics for users display session counts and time logged on in minutes

Jetspeed-2

November, 2005 123

Page Statistics

• Jetspeed gathers statistics about page activity and logs it to either a database or a CLF file. Statistics for pages display hit counts and render times in milliseconds

Technology

Jetspeed-2 Overview