The Jetspeed Profiler is a portal resource location rule-based engine. The profiler locates the following kinds of portal resources:
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.
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,...
Resolvers are Java classes that try to match criteria to find resources. Jetspeed provides several resolvers 'out of the box'.
| request | match request parameter |
| session | match session parameter |
| path | match the path portion of the URL to the PSML page |
| hard.coded | a hard-coded value, such as “default-page.psml” |
| user | match the name of the current authenticated user |
| mediatype | match the mediatype (HTML,XHTML..) |
| language | the browser’s preferred language |
| country | the browsers preferred country code |
| user.attribute | match a named user attribute (Portlet API) |
| user.agent | the name of the agent (browser) |
| hostname | match the hostname in the URL |
| navigation | directive: move algorithm to start search in new location |
| group.role.user | use fallback algorithm |
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:
| _user | Holds all user-specific pages. |
| _role | Holds all role-specific pages. |
| _group | Holds all group-specific pages. | >
| _subsite-root | Contains complete subsite trees, exactly like root tree. |
| 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. |
The profiler.xml Spring configuration file configures the profiler component.
| Constructor Argument | Description |
|---|---|
| (0) JETSPEED-INF/ojb/profiler_repository.xml | Holds the OJB database to POJO mapper for marshalling profile information to and from the persistent store. |
| (1) j1 | The default profiling rule. If a user does not have a profiling rule defined in the association table, this profiling rule is used. |
| (2) ProfileResolvers (ref bean) | The map of profiler resolver names to implementing resolver classes. New resolvers should be added to the ProfileResolver table. |