Return-Path:
+ Jetspeed 2.1.3 provides 2 installers:
+
+
+
+ To run the standard (minimal) installer: +
+ ++To run the Jetspeed Demo installer: +
+ +
+ The installers are capable of running on headless (i.e. no gui) machines, and will detect so automatically.
+ To force the installer in text mode manually, pass in the text parameter:
+
+ The installer will ask you to choose a database for storing the Jetspeed database. We provide a default Derby database for demo systems. + The Derby database runs in embedded mode inside the Jetspeed/Tomcat JVM. All other databases require additional configuration. + If you selected Derby, you can go with the default parameters provided. For all other databases you must first create an area to hold the Jetspeed tables. + For some databases this area is called a catalog, others call it a schema, while others call it a database. Consult your + database documentation for details on how to create a catalog or schema to hold the Jetspeed tables. Additionally, you may need to create a database user + to access the Jetspeed tables. Often it is required to grant access to the schemas (catalogs) for the given user. +
+Jetspeed supported database list: +
If you choose the manual database setup, then the database scripts will not be run and you will need to configure the database manually after the installation. + All database scripts are provided in the installation under the database directory. For your specific database, look for the corresponding directory name. + During installation, you will be prompted for the following fields after chosing your database types (except for Derby): +
+ Once you have entered all of your parameters, the installer will test the database connection before proceeding. + If the connection fails, please go back to the connection configuration setup and provide the correct parameters. + If you choose to continue, the database scripts will not be run and you will need to configure the database manually after the installation. + Once the installer verifies the database connection, you are ready to proceed with installation process. +
+
+ Please take note of the location where you are installing on your file system.
+ Also, on a Windows platform make sure to use a location path without spaces, e.g. NOT under C:\Program Files.
+
+ Once you have completed a successful install, you are ready to start the Jetspeed Portal. + On linux, here is an example where you have installed to the default location: +
+ ++ On windows, here is an example where you have installed to the default location: +
+ ++ The very first invocation of the portal requires anywhere from 10 seconds to 30 seconds for initial + startup and final installation. After starting the server, start up a web browser + and navigate to http://localhost:8080/jetspeed/portal +
++All preconfigured users have the same password as username (for example the admin user has the password admin) +If you installed with the Minimal installer, two test accounts are available: +
+ ++If you installed with the Demo installer, several additional test accounts are available: +
+ ++The Jetspeed Desktop is a client-side JSR-168 aggregation engine. +To accesss the Desktop, navigate your browser to http://localhost:8080/jetspeed/desktop +When switching between the /desktop and the /portal URLs, logout to start a new session. +
++ After running the installation, you can manually reinitialize the database or even switch to another database. + To do so, we provide an Ant script found under the database directory of your installed Jetspeed portal. + The database configuration is defined in the database.properties file. To reinitialize or change the database, + go to the database directory and edit the database.properties file, save it, and then run ant. +
+Here is a sample database configuration file: +
+ +If you are configuring a database for the first time after choosing Manual database setup in the installer, or want to try out
+ a different type of database, make sure to copy the specific JDBC driver for the database to the Tomcat shared/lib folder before running ant.
+ Note: for Derby, the needed driver is already placed there or available from the database/lib directory of your installed Jetspeed portal.
+ Below is a listing of common conventions used within + this document. +
++ Variables are represented as ${ + some_variable + }. This may signify a setting in Jetspeed or may + represent a setting within your environment. + Properties files are also capable of specifying + variables within them. +
++ For example, ${org.apache.jetspeed.server.home} + references either a property defined further up in + the properties file, a variable that has been + defined somehwere within the build process or + defined in another build file within Jetspeed. +
++ + Subversion (SVN) + + is used in the Jetspeed project to manage the source + files. SVN is very similar to CVS. For those user's + on Windows system who prefer non-command line access + we suggest using + + TortoiseSVN + + which plugs into your Windows Explorer view. For + those using the Eclipse IDE, the + Subclipse + plugin is available for SVN access. +
++ We will not go into the specifics of Maven as that + is beyond the scope of this document. However, here + are a few bits of standard maven jargon we feel is + important for you to know. +
+
+ You will see mention of a
+ maven repository
+ in this document. When you install Maven the .maven/
+ directory is created in your ${USER_HOME) directory.
+
+ Under .maven/ you will see a
+ repository
+ directory. This is were Maven stores all the jars
+ that it downloads when you run your builds. This is
+ also were Maven puts your jars and wars that you
+ build. They will be stored in a directory structure
+ that has the format of
+ ${groupId}/${projectId}/jars/${projectId}-{$version}.jar
+ for jar files and
+ ${groupId}/${projectId}/wars/${projectId}.war for
+ war files. The ${groupId}, ${projectId} and
+ ${version} variables are discussed later on in this
+ document. Jar and war files will also be created in
+ your project in the
+ /target
+ directory.
+
+ Now we're going to configure, setup and build a new + custom portal application using the Jetspeed-2 + maven-plugin. +
++ Maven2 install the plugins by it self, make sure you mention your repositories in your settings.xml +
++ Once you have the maven-plugin installed and set + properties as needed, generate a default portal + configuration using the plugin as follows: + +
++ You would need specify you database which would be used to creating portal schema. + jetspeed pluin have created an jetspeed-mvn-settings.xml, in root of project location + you need to fill properties, with correct database information. + + You also need to specify the tomcat location, where portal need to deployed make sure + tomcat version should be above 5.5.27 +
+ ++ Once your portal configuration and setup is ready, + you can build and install the portal application in + your local maven repository (as needed for + deployment) using the following standard maven goal. + +
++ You are now ready to deploy the new portal + application. For this, skip the following section on + building the Jetspeed 2 portal from source and + continue with the + deployment + section. +
++ Build the Jetspeed 2 portal directly from the source is + somewhat easier to do but should only be done if you + don't want to create a new, customizable portal. +
+
+ The Jetspeed 2 source contains a
+ jetspeed-mvn-settings-sample.xml
+ file which provides all of the required portal
+ configuration settings as described. You need copy this file to jetspeed-mvn-settings.xml
+
+ above
+
+ .
+
+ You should
+
+ not
+
+ define any of those properties in your
+ ${m2_HOME}/settings.xml
+ .
+
+
+ When you are going to deploy the portal as described
+ further below, you'll see references to the
+ org.apache.jetspeed.portal.home
+ which you can translate with the root folder of your
+ Jetspeed 2 source.
+
+ If you want to run the testcases when building the + Jetspeed 2 sources + and + don't want to use the default Derby test database, + you need to override the default test database + properties, similar to the production database + properties as described + + above + + : +
+ org.apache.jetspeed.test.database.default.name
+
+
+ org.apache.jetspeed.test.database.url
+
+
+ org.apache.jetspeed.test.database.user
+
+
+ org.apache.jetspeed.test.database.password
+
+
+ org.apache.jetspeed.test.database.driver
+
+
+ org.apache.jetspeed.test.database.drivers.path
+
+ + For a full build and installation of the portal and + the demo portlet applications in your local maven + repository run: + +
++ But, if you also want to run the testcases during + the build run the following instead: + +
++ You are now ready to deploy the Jetspeed 2 Portal. +
++ We currently only cover deploying to Tomcat 5 or + Tomcat 5.5. +
++ Information about deployment to other application + servers can be found at the The Jetspeed 2 + + Wiki + + . +
++ To deploy a default Jetspeed 2 portal, including the + demo portlet applications, run the following in a + separate + console: + + + Note: the + + maven-plugin documentation + + described other goals you can use to customize + the deployment to your taste. + +
++ The final step is starting up your Tomcat server and + the portal will automatically install any deployed + portlet applications. +
+
+ Then you can access the portal with your browser at:
+
+ or replace "jetspeed" in the above url with the name
+ of you own portal application (
+
+ ${org.apache.jetspeed.portal.artifactId}
+
+ ).
+
+ With the default Jetspeed 2 portal deployment, + several example user accounts are inserted into the + portal database with which you can logon to the + portal: +
username | +password | +roles | +
---|---|---|
+ admin
+ |
+
+ admin
+ |
+
+ admin, manager, user
+ |
+
+ manager
+ |
+
+ manager
+ |
+
+ manager, user
+ |
+
+ jetspeed
+ |
+
+ jetspeed
+ |
+
+ manager
+ |
+
+ user
+ |
+
+ user
+ |
+
+ user
+ |
+
+ tomcat
+ |
+
+ tomcat
+ |
+ + |
+ It is expected that the user is familiar with both the + Apache Maven + project management tool. +
++ If you have not already done so, download and install + Maven2 + . +
++ Jetspeed's security model requires a database to + authorize users and to retain the user information. + Jetspeed security should work with any JDBC 2.0 + compliant driver. The following databases are tested: +
+ The database configuration will be setup during the + installation process. If you are not going to use the + default Derby database, you need to select another database + during installation. +
++ In theory, Jetspeed 2 portals can be run under any + servlet container supporting the 2.4 specification or + greater. Successful Jetspeed 2 portal applications have + been deployed using: +
+ Jetspeed 2 can use the Tomcat Manager application + for managing portlet applications with the Portlet + Application Lifecycle Manager Portlet (PALM). To be + able to do so it needs a configured Tomcat user with + the predefined 'manager' role in the + ${org.apache.jetspeed.server.home}/conf/tomcat-users.xml. +
+
+ A minimal example tomcat-users.xml can look like:
+
+
+ The attribute values for username and password
+ must correspond to the specified values for
+
+ ${org.apache.jetspeed.services.autodeployment.user}
+
+ and
+
+ ${org.apache.jetspeed.services.autodeployment.user}
+
+ as described above.
+
+
+ To have redeployment and undeployment working + properly when using Tomcat 5.5.9 on Windows you have + to set the global Context attribute "antiJARLocking" + to true. +
++ In + ${org.apache.jetspeed.server.home}\conf\context.xml + use: + +
++ Jetty can be used for a production deployment but it is + most commonly used to quickly test customizations + without interfering with the production servlet + container. It does not require any special + configuration. +
++ Depending on what you want to do, you have the choice of + installing Jetspeed from a binary release or from the + sources. If you want to modify the core functionality of + Jetspeed or contribute to the development of Jetspeed, + you need to work with the sources. If you are only + interested in building your own custom enterprise + portal, you can start with a binary release of Jetspeed. + Most people should start with the binary distribution. +
++ Your installation instructions will depend on whether + you are + + building from source + + or + + building from a binary distribution + + or + + installing with Jetspeed-2 installer + + . +
++1. override web.xml in custom build +2. edit web.xml + * remove security-constraints "Login" + * remove LoginProxy, LoginServlet, LoginError, LoginRedirector, ... + * remove servlet-mapping for above servlets +
++ The portal provides a consolidated view of multiple content sources, or portlets, in a single browser display. + The process of consolidating and rendering this content together is known as aggregation. + In Jetspeed, the aggregator is made up of several pluggable Spring components that plug into the Jetspeed engine. +
+List of Aggregators:
+Component Name | +Description | +Multithreaded? | +JSR-168 Caching? | +
---|---|---|---|
PageAggregator | +Given a PSML page, aggregates the content of all portlets on that page. | +no | +yes | +
AsyncPageAggregator | +A multi-threaded, asynchronous PSML page aggregator. | +yes | +yes | +
PortletAggregator | +Renders the content of one single portlet. | +no* | +yes | +
AsyncPageAggregator + CommonJ | +A multi-threaded, asynchronous PSML page aggregator running CommonJ Work Monitor threads, tested only with IBM Websphere 6.1 only. | +yes | +yes | +
+
+ ++
+ ++ The default aggregator is single-threaded. To switch to multi-threaded, + edit the pipelines.xml spring configuration file: +
+ ++
+ ++ For the multithreaded aggregator, you can override the default setting + for rendering timeout for a specific portlet. This value is set in milliseconds + and represents the timeout value that Jetspeed will give the portlet to complete + rendering before it gives up. +
+ ++
+ +Running mulithreaded aggregation with Jetspeed requires the following configuration steps. + Note that steps 1 and 2 are required for all Websphere installations and are not specific to multithreaded aggregation. +
+Configure the WEB-INF/web.xml to use the PortalFilter for logging in by uncommented the PortalFilter and its mapping:
+ +Edit the default-page.psml, changing the login portlet to the filter-based login portlet as shown below. + Make sure to also change the fragment id. Change:
+ +to ..
+ ++Some webcontainers like WebSphere 5.x derive critical information of the HttpServletRequest dynamically from the current application context. +This means that in an invoked portlet application, the original Portal request, as stored in the RequestContext, for example doesn't returns the Portal contextPath, servletPath and HttpSession of the Portal application. You'll get the same object references as in the current application HttpServletRequest. +Because of this, simple things as portal level login through a custom portlet isn't possible in these web containers. +
++To solve this, an additional PortalRequest wrapper will be used which registers the initial (portal) object references from a supplied request and always returns those, +instead of delagating to the wrapped request. +Which wrapper is used is handled by a new PortalRequestFactory which can be specified in the springframework configuration. +For other web containers like Tomcat which doesn't have this "problem", nothing has to be specified (none is by default), in which case the request will be wrapped in an HttpServletRequestWrapper to maintain the same level of wrapping (needed for easy access to the original request in ServletPortletInvoker. +
+Edit WEB-INF/assembly/wps.xml, and uncomment the one bean found there
+ +Swap out the (org.apache.jetspeed.aggregator.PageAggregator) with the multithreaded aggregation engine in WEB-INF/assembly/pipelines.xml: +
+ +You can replace the default portlet request/response unwrapper with a third-party module in WEB-INF/assembly/pluto-factories.xml.
+Because the servlet request object of a servlet container could not be thread-safe under Jetspeed parallel rendering mode, the third-party unwrapper module can provide a thread-safe implementation by decorating the original request object.
+Here's an example setting for third-party unwrapper module:
+ +If you want to use Commonj Work Manager provided by the container, uncomment the followings in WEB-INF/assembly/aggregation.xml:
+ ++ Also replace all references to org.apache.jetspeed.aggregator.WorkerMonitor with org.apache.jetspeed.aggregator.CommonjWorkerMonitor in WEB-INF/assembly/aggregation.xml. +
++The Jetspeed XML AJAX API is an XML-based API provided to AJAX clients for making +asynchronous requests to Jetspeed-2 services.
++Typical use cases: +
++All AJAX XML API requests run through +a standard Jetspeed Pipeline request. This means that you can configure your AJAX +request with the usual array of Jetspeed components. The default AJAX pipeline secures +access to all requests. Each AJAX action may have its own security constraints. All +requests made to a page will use the declarative security constraints configured for that page. +AJAX request actions are enforced under edit or view mode, depending on the nature of the action. +
++The AJAX XML API is simply a HTTP request-based API, communicating over a simple REST (Representational State Transfer) protocol. +The API is accessed over HTTP via the "ajaxapi" servlet path on the portal URL: + +
+Request Parameters specify the requested API action, and additional API parameters. +The page that a request is referencing is implied in the HTTP URL. +Thus if we are making a request to modify a page, the page is specified in the HTTP URL: + +The page location algorithm using standard Jetspeed Profiling rules to locate the page. +A page is actually not required in the URL, since the Jetspeed Profiler will locate the page +for you. Example: + +goes to the default page for the current user. +
+Request Parameters are specific to each API. One request parameter, the "action" parameter, + is almost always required, (except in the default case). The default action is "action=getpage" +which returns an XML representation of the profile-located page in PSML. (PSML is an XML format). +See the table below for specific examples of request parameters. +
+Here are the APIs currently available: +
+API: | +getpage | +|||
Component: | +AjaxGetPage | +|||
Description: | +Get Page retrieves a page from the Page Manager store in PSML format. + | +|||
Parameters: | +
page | +implied in the URL | +
action | +getportlets (optional, this is the default action) | +
API: | +moveabs | +|||||||||
Component: | +AjaxMovePortletAbsolute | +|||||||||
Description: | +Move a portlet on a page to an absolute position specified in the row and col request parameters. | +|||||||||
Parameters: | +
page | +implied in the URL | +
action | +moveabs | +
id | +the portlet PSML fragment id of the portlet to be moved | +
row | +the absolute new row location to place the portlet fragment (zero based) | +
col | +the absolute new column location to place the portlet fragment (zero based) | +
APIs: | +moveleft, moveright, moveup, movedown | +|||||
Components: | +AjaxMovePortletLeft, AjaxMovePortletRight, AjaxMovePortletUp, AjaxMoveDown | +|||||
Description: | +Move a portlet on a page relatively one position, based on the action. | +|||||
Parameters: | +
page | +implied in the URL | +
action | +moveleft, moveright, moveup, movedown | +
id | +the portlet PSML fragment id of the portlet to be moved | +
API: | +move | +|||||||||||||||
Component: | +AjaxMovePortlet | +|||||||||||||||
Description: | +Move a portlet on a page to a cartesian position (x,y,z,width,height) from request parameters. | +|||||||||||||||
Parameters: | +
page | +implied in the URL | +
action | +move | +
id | +the portlet PSML fragment id of the portlet to be moved | +
x | +the portlet cartesian X position | +
y | +the portlet cartesian Y position | +
z | +the portlte cartesian Z position | +
width | +the width of the portlet | +
height | +the height cartesian Y position | +
API: | +add | +|||||||||
Component: | +AjaxAddPortlet | +|||||||||
Description: | +Adds a new portlet to the current page. The portlet can be added at a specified row and column. + If either the row or column or not specified, defaults to zero respectively. | +|||||||||
Parameters: | +
page | +implied in the URL | +
action | +add | +
id | +The portlet full name to be placed on the page, using Jetspeed Portlet Naming (PortletApplicationName::PortletName) | +
row | +optional: the absolute new row location to place the new portlet fragment (zero based) | +
col | +optional: the absolute new column location to place the new portlet fragment (zero based) | +
API: | +remove | +|||||
Component: | +AjaxRemovePortlet | +|||||
Description: | +Removes a new portlet from the current page. | +|||||
Parameters: | +
page | +implied in the URL | +
action | +remove | +
id | +the portlet PSML fragment id of the portlet to be removed | +
API: | +getportlets | +|||||
Component: | +AjaxGetPortlets | +|||||
Description: | +Get Portlets retrieves the (sorted) portlet list available to the current subject, filtered + the portlet list, and returning portlets which the current subject may view. + The Jetspeed (JAAS) security policy enforces this filtering. Portlets are returned + in XML format, with name, displayName, and description for each portlet. | +|||||
Parameters: | +
page | +implied in the URL | +
action | +getportlets | +
filter | +not yet implemented. A query filter to be defined. | +
API: | +permissions | +|||||||||||||
Component: | +AjaxSecurityPermissions | +|||||||||||||
Description: | +Security Permissions Maintenance to add, update, and remove permissions from the Jetspeed security policy | +|||||||||||||
Parameters: | +
action | +permissions | +
method | +the method to execute: must be of value: add | update | remove | +
type | +the type of permission being manipulated: portlet | folder | page | +
resource | +the name of the portal resource being manipulated | +
roles | +comma-separated list of roles, only valid for methods: add, update | +
actions | +comma-separated list of actions, only valid for methods: add, update | +
oldactions | +comma-separated list of previous actions, only valid for methods: update | +
API: | +getmenus | +|||
Component: | +AjaxGetMenus | +|||
Description: | +Retrieves all menus for the current page (implied in URL) | +|||
Parameters: | +
action | +getmenus | +
page | +(implied in URL) | +
API: | +getmenu | +|||
Component: | +AjaxGetMenu | +|||
Description: | +Retrieves the menu definition for a given menu | +|||
Parameters: | +
action | +getmenu | +
menu | +name of the menu to retrieve (menu definition may change per page) | +
API: | +getmenus | +|||||||||
Component: | +AjaxChangeWindow | +|||||||||
Description: | +Changes a portlet window's Window State or Portlet Mode | +|||||||||
Parameters: | +
action | +window | +
id | +window id of the portlet to be modified | +
state | +A portlet api valid window state or extended window state (normal | maximized | minimized) | +
mode | +A portlet api valid portlet mode or extended portlet mode (view | edit | help | print) | +
page | +Implied in URL | +
API: | +getuseinfo | +|
Component: | +AjaxGetUserInformation | +|
Description: | +Returns information about the currently logged in user. Can be used for example in AJAX based portlets to retrieve the userinfo in a more robust way. Will return success only if a user is currenly logged in, otherwise will return false. | +|
Parameters: | +
action | +getuserinfo | +
API: | +getuseinfo | +|||||||||
Component: | +AjaxGetUserList | +|||||||||
Description: | +Provides basic information (username, ip-address, number of sessions and status) about currently logged in users in xml-format. Optionally it can also provide more detailed userinformation, number of guest sessions and include offline users as well. | +|||||||||
Parameters: | +
action | +getuserinfo | +
userinfo | +Whether we should include also userinfo (true | false [default]) | +
offline | +Whether we should include offline users (true | false [default]) | +
guest | +Whether we should return also the guest sessions (true | false [default]) | +
all | +If set to true, will return every bits and piece there is (true | false [default]) | +
+ By default the private information (emails, etc..) is protected with + RolesSecurityBehavior security, but can be changed in AJAX configuration + by altering the protectionScope constructor value to either "all" to protect + even the basic information or to "none" when everything will be shown for everyone (not wise on production). + The default value "private" will show just the basic information of online/offline users and number of guest sessions, + as the "private-offline" will not show even the offline users. Possible protectionScope values are "all", + "private-offline", "private" and "none". +
+
+The AjaxRequestService
is a Spring component that handles AJAX requests.
+It is hooked into the AJAX Pipeline for special processing
+of AJAX request. Here is the Spring Assembly. Each API is configured in the Ajax Service.
+
+ + Note: The maven-plugin currently only supports the + Tomcat Server 5.0.x or 5.5.x + +
+Property | +Description | +Default value | +
---|---|---|
+ org.apache.jetspeed.server.home
+ |
+
+ The root folder of your Tomcat server
+ installation.
+ + Example: + ${CATALINA_HOME}/
+ .
+ |
+ + no default + | +
+ org.apache.jetspeed.server.shared
+ |
+
+ The location of the shared jars in your Tomcat
+ installation.
+ + Example: +
+ ${org.apache.jetspeed.server.home}/shared/lib/
+
+ |
+ + no default + | +
+ org.apache.jetspeed.deploy.war.dir
+ |
+
+ The location of web applications in your Tomcat
+ installation.
+ + Example: +
+ ${org.apache.jetspeed.server.home}/webapps/
+
+ |
+ + no default + | +
+
+ org.apache.jetspeed.services.autodeployment.user
+
+ |
+
+ A Tomcat user with the manager role.
+ + Used to access the Tomcat Manager application + from within the portal, explained below. + |
+ + no default + | +
+
+ org.apache.jetspeed.services.autodeployment.password
+
+ |
+
+ The password of the Tomcat user above.
+ + Used to access the Tomcat Manager application + from within the portal, explained below. + |
+ + no default + | +
+
+ org.apache.jetspeed.catalina.version.major
+
+ |
+
+ The major version of the Tomcat server you are
+ using: 5 or 5.5
+ + Example: + 5.5
+ |
+ + no default + | +
+ Jetspeed-2 and its maven-plugin uses, as well as + provides, by default a Derby database. +
++ If you want to use a different database you will need to + override the following properties: +
+Property | +Description | +Default value | +
---|---|---|
+
+ org.apache.jetspeed.production.database.default.name
+
+ |
+
+ The type of database you are using. Used for sql
+ script generation with Torque.
+ + Currently supported databases (with + corresponding Torque target database name): +
|
+ derby | +
+
+ org.apache.jetspeed.production.database.url
+
+ |
+ The jdbc connection url | +jdbc:derby:${org.apache.jetspeed.derbydatabase.path}/productiondb;create=true | +
+
+ org.apache.jetspeed.production.database.user
+
+ |
+ The database user name to connect with. | +empty | +
+
+ org.apache.jetspeed.production.database.password
+
+ |
+ + The database user its password to connect with. + | ++ empty + | +
+
+ org.apache.jetspeed.production.database.driver
+
+ |
+ The jdbc driver class name | +org.apache.derby.EmbeddedDriver | +
+
+ org.apache.jetspeed.production.jdbc.drivers.path
+
+ |
+
+ A Java classpath style path to the jdbc driver
+ classes or jar(s) needed for connecting to the
+ database.
+ + Example: +
+ /lib/ojdbc14.jar;/lib/nls_charset12.jar
+
+ |
+ + empty + | +