You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by ta...@apache.org on 2009/04/24 00:28:39 UTC
svn commit: r768082 [3/8] - in
/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs: ./
adminguide/ adminguide/images/ deployguide/ deployguide/images/ devguide/
usersguide/
Modified: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/config-overrides.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/config-overrides.xml?rev=768082&r1=768081&r2=768082&view=diff
==============================================================================
--- portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/config-overrides.xml (original)
+++ portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/config-overrides.xml Thu Apr 23 22:28:35 2009
@@ -17,16 +17,168 @@
-->
<document>
<properties>
- <title>User Attributes</title>
- <subtitle>User Information Configuration</subtitle>
+ <title>Spring Configuration Overrides</title>
+ <subtitle>Spring Configuration Overrides</subtitle>
<authors>
<person name="David Sean Taylor" email="taylor@apache.org"/>
</authors>
</properties>
<body>
-<section name="Override Properties">
+<section name="Spring Configuration Overrides">
+
+ <p>
+ Spring Configuration Overrides, located in <strong><code>/WEB-INF/assembly/override/</code></strong>, are loaded over the configuration files found in the parent assembly folder (<strong><code>/WEB-INF/assembly/</code></strong>).
+ Use the override folder to modify the default assembly configuration. There are examples of overrides in the <strong><code>/WEB-INF/assembly/alternate/</code></strong> directory.
+ Note that the configuration files found in the alternate directory are only examples. They are not actively used. If you wanted to use one of the alternate configuration files, copy it into the overrides directory,
+ and then modify it from there.
+ </p>
+ <p>
+ Spring beans are replaced by name. So the configuration files do not need to match by file name when overriding. If you are only overriding one bean though,
+ it might be easier to just replace the bean in the main Jetspeed Spring container by dropping in a new file with only that one bean.
+ </p>
+<subsection name='Example Spring Override'>
+<p>For example, say if we were to override the CapabilityValve found in Jetspeed's pipelines.xml file:</p>
+<source><![CDATA[
+ <bean id="capabilityValve"
+ class="org.apache.jetspeed.capabilities.impl.CapabilityValveImpl"
+ init-method="initialize"
+ >
+ <constructor-arg>
+ <ref bean="org.apache.jetspeed.capabilities.Capabilities" />
+ </constructor-arg>
+ </bean>
+]]></source>
+ <p>
+The pipelines.xml has a lot of beans. We only need to replace the one bean, capabilityValve, with our implementation. Note the bean id is the same, the impl is different:
+ </p>
+<source><![CDATA[
+ <bean id="capabilityValve"
+ class="com.ace.capabilities.impl.AceCapabilityValveImpl"
+ init-method="initialize"
+ >
+ <constructor-arg>
+ <ref bean="com.ace.services.AceDataService" />
+ </constructor-arg>
+ </bean>
+]]></source>
+<p>Saving this one bean in a file named capability-valve-override.xml would clearly define what is being overriden.</p>
+</subsection>
+ <p>
+ Commonly used overrides in Jetspeed are:
+ <ul>
+ <li>DBPSML</li>
+ <li>Versioned Deployment</li>
+ <li>Adding a Jetspeed Service</li>
+ <li>Pipelines or tweaking a feature</li>
+ </ul>
+ </p>
+<subsection name='DBPSML'>
+<p>PSML represents the pages in your portal. There can be lots of them. The default implementation stores the PSML files on the file system.
+A secondary implementation stores the files in the database. Storing in the database is necessary when deploying to a clustered Jetspeed distribution,
+or when you have tens of thousands of users where performance is required. Provided in the alternate directory is a DBPSML alternate configuration, db-page-manager.xml.
+You can take this file and copy it into your overrides directory. It will override the page-manager.xml beans by name.
+</p>
+<source><![CDATA[
+ <bean id="org.apache.jetspeed.page.PageManagerImpl"
+ name="pageManagerImpl"
+ init-method="init"
+ class="org.apache.jetspeed.page.impl.DatabasePageManager">
+ <!-- OJB configuration file resource path -->
+ <constructor-arg index="0"><value>JETSPEED-INF/ojb/page-manager-repository.xml</value></constructor-arg>
+ <!-- permissions security enabled flag, default=false -->
+ <constructor-arg index="1"><value>false</value></constructor-arg>
+ <!-- constraints security enabled flag, default=true -->
+ <constructor-arg index="2"><value>true</value></constructor-arg>
+ <!-- folder/page/link cache -->
+ <constructor-arg index="3"><ref bean="pageManagerOidCache"/></constructor-arg>
+ <!-- folder/page/link path cache -->
+ <constructor-arg index="4"><ref bean="pageManagerPathCache"/></constructor-arg>
+ </bean>
+]]></source>
+</subsection>
+<subsection name="Versioned Deployment">
+<p>The default Jetspeed Deployer, although it works well for development on Tomcat, doesn't work well in clustered environments.
+We have implement a second, Versioned Portlet Application Manager for clustered environments.
+The Node Manager implementation will most likely be deprecated in the future. We are running into
+limitations with the NodeManager-based cluster support when deploying
+to clusters with replicated databases as well as replicated app servers.
+The default PAM (Portlet Application Manager) is not-appropriate for many deployments of the
+portal. This second version of the PAM has no listeners,
+and a simpler deployment algorithm based on a version number supplied in the jetspeed-portlet.xml
+metadata
+If this field is not found, or if it is equal to or less than the version in the database,
+then the PA will not be deployed.
+This will allow for dropping in 2..n PAs in a cluster, without re-registering. The problem
+with re-registering is that the registry algorithm deep deletes the old PA def from the database,
+create a new PA, with all new OIDs, invalidating all other PAs and portlets on other nodes
+in the cluster.
+</p>
+<source><![CDATA[
+<bean id="deployFactory" class="org.apache.jetspeed.tools.deploy.JetspeedDeployFactory"/>
+ <bean id="org.apache.jetspeed.tools.pamanager.PortletApplicationManager"
+ class="org.apache.jetspeed.tools.pamanager.VersionedPortletApplicationManager" init-method="start" destroy-method="stop"
+ >
+ <constructor-arg><ref bean="portletFactory"/></constructor-arg>
+ <constructor-arg><ref bean="org.apache.jetspeed.components.portletregistry.PortletRegistry"/></constructor-arg>
+ <constructor-arg><ref bean="org.apache.jetspeed.components.portletentity.PortletEntityAccessComponent"/></constructor-arg>
+ <constructor-arg><ref bean="org.apache.jetspeed.container.window.PortletWindowAccessor"/></constructor-arg>
+ <constructor-arg><ref bean="org.apache.jetspeed.security.PermissionManager"/></constructor-arg>
+ <constructor-arg><ref bean="org.apache.jetspeed.search.SearchEngine"/></constructor-arg>
+ <constructor-arg><ref bean="org.apache.jetspeed.security.RoleManager"/></constructor-arg>
+ <!-- role principals to assign a default permission(s) during deployment of a Portlet Application -->
+ <constructor-arg >
+ <list>
+ <value>user</value>
+ </list>
+ </constructor-arg>
+
+ <!-- application root -->
+ <constructor-arg>
+ <value>${applicationRoot}</value>
+ </constructor-arg>
+
+
+ <!-- optional configuration for automatic creation of not yet existing roles as defined in the deployed web.xml:
+ <property name="autoCreateRoles"><value>true</value></property>
+ -->
+ <!-- optional descriptor change monitor check interval in seconds (0: disabled, default: 10):
+ <property name="descriptorChangeMonitorInterval"><value>10</value></property>
+ -->
+ <!-- optional max PA start retries in case of an error registering ths PA (0: do not retry, default: 10):
+ this was introduced because of DB constraint validation errors in clustered environments
+ see https://issues.apache.org/jira/browse/JS2-666
+ <property name="maxRetriedStarts"><value>10</value></property>
+ -->
+ </bean>
+]]></source>
+<p>
+Provided in the alternate directory is a deployment alternate configuration, deployment.xml. You can take this file and copy it into your overrides directory. It will override the deployment.xml beans by name.
+</p>
+</subsection>
+<subsection name="Adding Jetspeed Services">
+ <p>Occasionally you may write your own service to run inside Jetspeed. You will need to add your service to the PortalServices bean.
+ Unfortunately this requires cutting and pasting the entire PortalServices bean, and adding your service to the map in your overriden jetspeed-services.xml:</p>
+<source><![CDATA[
+
+<beans>
+ <!-- Portlet Services -->
+ <bean id="PortalServices"
+ class="org.apache.jetspeed.services.JetspeedPortletServices" >
+ <constructor-arg>
+ <map>
+ ...
+ <entry key="MyNewService">
+ <ref bean="com.ace.services.MyNewService"/>
+ </entry>
+ </map>
+ </constructor-arg>
+ </bean>
+</beans>
+]]></source>
<p>
+In this case take the jetspeed-services.xml, copy it to your WEB-INF/assembly/override directory, and modify it there to add your new service
</p>
+</subsection>
</section>
</body>
</document>
Modified: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/config-spring.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/config-spring.xml?rev=768082&r1=768081&r2=768082&view=diff
==============================================================================
--- portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/config-spring.xml (original)
+++ portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/config-spring.xml Thu Apr 23 22:28:35 2009
@@ -17,16 +17,107 @@
-->
<document>
<properties>
- <title>Spring Overrides Configuration</title>
- <subtitle>Spring Overrides Configuration</subtitle>
+ <title>Spring Framework Introduction</title>
+ <subtitle>Spring Framework Introduction</subtitle>
<authors>
<person name="David Sean Taylor" email="taylor@apache.org"/>
</authors>
</properties>
- <body>
-<section name="Spring Overrides Configuration">
-<p>
-</p>
-</section>
-</body>
+ <body>
+
+ <section name="Spring Introduction">
+ <p>
+ Spring is a unique Java application framework meant to simplify the development of applications. Whereas Enterprise Java Beans are very complex to use, the <a href="http://www.springframework.org">Spring Framework</a> is an easy to use and understand framework for enterprise applications. Spring focuses on:
+ <ul>
+ <li>Providing a simple way to manage an object's lifetime and relationships (through Dependency Injection).</li>
+ <li>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.</li>
+ <li>Promoting best software development practices. For example, Spring is designed to always promote test-driven development and eliminate the need for factories and singletons.</li>
+ <li>Inversion of Control. Spring is an application container supporting interceptions and declarative aspect oriented programming.</li>
+ </ul>
+ Spring is an open source project; however it is not housed at Apache.
+ </p>
+
+ <subsection name="Jetspeed + Spring">
+ <p>
+ The Jetspeed portal is configured completely as a Spring application. All services in Jetspeed are constructed and configured as Spring beans.
+ Jetspeed runs in a Spring container. Spring provides a great environment for customization your deployment of Jetspeed. Some of the
+ added benefits of Spring in Jetspeed are:
+ <ul>
+ <li>Aspect Oriented Programming in the Spring configuration files.</li>
+ <li>Hot swapping: allows implementation hiding and swapping.</li>
+ <li>Failover: failover to next component when a component fails.</li>
+ <li>Multicasting: multicasting of method invocation to multiple components.</li>
+ <li>Lifecycle management: starting, pausing and resuming components.</li>
+ </ul>
+ </p>
+ </subsection>
+
+ <subsection name="Components run in a Spring Container">
+ <p>
+ Jetspeed, as a Spring application, is a collection of components, or services, 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 as shown in the diagram below. Note this is by no way an inclusive list of all Jetspeed services wired in Spring:
+ </p>
+ <p>
+ <img src="images/jetspeed-portal-container.jpg" border="0"/><br/><br/>
+ </p>
+ </subsection>
+
+
+ <subsection name="Programming to the Jetspeed API">
+ <p>
+ When developing Jetspeed core, Jetspeed extensions, or Jetspeed Administrative Portlets, you should always program to the Jetspeed API.
+ All Jetspeed Components are wired together on interfaces, not class implementations. This contract-by-interface approach to programming makes for a powerful
+ and extensible programming model for developing enterprise portal applications. When you are configuring your Jetspeed Spring components (beans), you will see
+ that components have their dependencies wired in to other Jetspeed components via dependency injection. The injected dependencies are always interfaces.
+ 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:
+ </p>
+ <p>
+ <source><![CDATA[
+<bean id='PortalAdministrationImpl' init-method="start"
+ class='org.apache.jetspeed.administration.PortalAdministrationImpl'>
+ <constructor-arg index='0'>
+ <ref bean="org.apache.jetspeed.security.UserManager"/>
+ </constructor-arg>
+ <constructor-arg index='1'>
+ <ref bean="org.apache.jetspeed.security.RoleManager"/>
+ </constructor-arg>
+ <constructor-arg index='2'>
+ <ref bean="org.apache.jetspeed.security.GroupManager"/>
+ </constructor-arg>
+ <constructor-arg index='3'>
+ <ref bean="org.apache.jetspeed.page.PageManager"/>
+ </constructor-arg>
+ <constructor-arg index='4'>
+ <ref bean="org.apache.jetspeed.prefs.PreferencesProvider"/>
+ </constructor-arg>
+ <constructor-arg index='5'>
+ <ref bean="org.apache.jetspeed.profiler.Profiler"/>
+ </constructor-arg>
+ <constructor-arg index='6'>
+ <ref bean="mailSender"/>
+ </constructor-arg>
+ <constructor-arg index='7'>
+ <ref bean="adminVelocityEngine"/>
+ </constructor-arg>
+</bean>
+ ]]></source>
+ </p>
+ <p>And here is the Java code constructor matching the Spring configuration. Notice that the dependencies injected are interfaces, not concrete class implementations:
+ </p>
+ <source><![CDATA[
+public PortalAdministrationImpl( UserManager userManager,
+ RoleManager roleManager,
+ GroupManager groupManager,
+ PageManager pageManager,
+ PreferencesProvider preferences,
+ Profiler profiler,
+ JavaMailSender mailSender,
+ VelocityEngine velocityEngine)
+ ]]></source>
+
+ </subsection>
+
+ </section>
+ </body>
</document>
Modified: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/config-sso.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/config-sso.xml?rev=768082&r1=768081&r2=768082&view=diff
==============================================================================
--- portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/config-sso.xml (original)
+++ portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/config-sso.xml Thu Apr 23 22:28:35 2009
@@ -1,32 +1,215 @@
<?xml version="1.0"?>
<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
-->
<document>
- <properties>
- <title>Jetspeed SSO Configuration</title>
- <subtitle>Jetspeed SSO Configuration</subtitle>
+<properties>
+ <title>Guide to Federated Security</title>
+ <subtitle>Federated Security Configuration Overview</subtitle>
<authors>
- <person name="David Sean Taylor" email="taylor@apache.org"/>
+ <person name="David Sean Taylor" email="taylor@apache.org" />
</authors>
- </properties>
- <body>
-<section name="Jetspeed SSO Configuration">
+</properties>
+<body>
+
+<section name="SSO and Federated Identify Management">
+ <p>
+
+SSO, or Single Signon, is a way for organizations to centralize their identity management and authentication needs in a consolidated, single solution across multiple applications in the enterprise.
+There are quite a few solutions available to enterprise to implement SSO with. Jetspeed classifies SSO in two categories:
+</p>
+<ul>
+<li>Jetspeed SSO</li>
+<li>External Identity Management Solutions</li>
+</ul>
+<p>
+The first, Jetspeed SSO, is a rather simpler solution for enterprise applications who do not need the complexity of a robust identity management SSO solution. In this case, Jetspeed provides a credential store
+for user credentials. Jetspeed can store encrypted credentials for users or groups of users to external sites. The second solution requires a third party open source project or product. In this case, Jetspeed
+integrates with an external SSO solution. These external solutions can often a single-signon solution for an organization, or even a federation of organizations.
+</p>
+<subsection name='Jetspeed SSO'>
+<p>
+Jetspeed SSO uses Jetspeed and Java security to implement a set of services and portlets for storing credentials. A <a href='../adminguide/sso.html'>management administrative portlet</a> allows the editing of SSO sites and remote credentials.
+Jetspeed SSO comes with a secure IFrame and Web Content set of portlets. These portlets allow you to secure access to external sites.
+Authentication suport includes:
+</p>
+<ul><li><b>Basic authentication</b> is the default and can be supported effectively without even setting the <b>sso.type</b> preference.
+Simply provide credentials for the domain, and basic authentication defaults. The credentials will not be sent preemptively,
+but if a 401 request is returned for Basic authentication, it will be handled properly.
+This is equivalent to setting the preference sso.type=basic (or sso.type=html (old - now deprecated in favor of calling it <b>basic</b>).
+if you set sso.type=basic.preemptive, it will send the credentials preemptively.
+</li>
+<li><b>URL authentication</b> (query args) is supported as <b>sso.type=url</b> or <b>sso.type=url.base64</b>.
+By definition, this type of authentication is <quote>preemptive</quote>, so no distinction is made
+there.
+</li>
+<li>
+<b>Form-authentication</b> is supported with <b>sso.type=form</b> (which is equivalent to sso.type=form.post - you can also specify sso.type=form.get,
+if GET protocol is used on the login form). This form also requires a bunch of other data
+( e.g. the action URL, other args, names of the fields for credentials, etc.).
+All of this is in an example that is in the demo portlet.xml.
+Form-based authentication is also considred "preemptive", in that it authenticates before any other
+content is read. However, it only does it once. If it succeeds, all should be well.
+If it fails, the user will have to login by hand (since the initial content URL will
+cause a redirect to the login page).
+</li>
+<p>Here are some examples of preferences that can be set for the SSO IFrame and SSO Content portlets:</p>
+<source><![CDATA[
+ <preference>
+ <name>sso.type</name>
+ <value>basic | url | form</value>
+ </preference>
+ <preference>
+ <name>sso.url.Principal</name>
+ <value>sso-principal</value>
+ </preference>
+ <preference>
+ <name>sso.url.Credential</name>
+ <value>sso-credential</value>
+ </preference>
+ <preference>
+ <name>SRC</name>
+ <value>http://www.nytimes.com</value>
+ </preference>
+ <preference>
+ <name>sso.type</name>
+ <value>form</value>
+ </preference>
+ <preference>
+ <name>sso.form.Action</name>
+ <value>http://www.nytimes.com/auth/login</value>
+ </preference>
+ <preference>
+ <name>sso.form.Principal</name>
+ <value>USERID</value>
+ </preference>
+ <preference>
+ <name>sso.form.Credential</name>
+ <value>PASSWORD</value>
+ </preference>
+ <preference>
+ <name>sso.form.Args</name>
+ <value>Submit2=Log In;OP=;OQ=;is_continue=false</value>
+ </preference>
+]]></source>
+
+</ul>
+</subsection>
+<subsection name='Integrating with External SSO'>
+ <p>
+ To enable an identity management service, such as Site Minder, or Shibbboleth (see below), there are some general guidelines for integrating your SSO solution with Jetspeed.
+
+
+ remove the
+ Login Portlet from the custom build and delegate authentication to the authentication
+ provider. Upon successful authentication, redirect to the portal.
+
+ <ol>
+ <li>Remove the Login Portlet from your custom home page. You will no longer need it. The third party SSO will handle all authentication. You will need to
+ configure the third party SSO to redirect to the Jetspeed portal upon successful authentication. All authentication activities are removed from Jetspeed.
+ </li>
+ <li>Modify the Jetspeed web.xml to include any required settings for your SSO solution. You might need to enable this filter and mapping:
+<source><![CDATA[
+ <filter>
+ <filter-name>PortalFilter</filter-name>
+ <filter-class>org.apache.jetspeed.login.filter.PortalFilter</filter-class>
+ </filter>
+ <filter-mapping>
+ <filter-name>PortalFilter</filter-name>
+ <url-pattern>/*</url-pattern>
+ </filter-mapping>
+]]></source>
+ </li>
+ <li>Additional edits to the Jetspeed web.xml recommended:</li>
+ <ul>
+ <li>remove security-config for the login portlet
+<source><![CDATA[
+ <login-config>
+ <auth-method>FORM</auth-method>
+ <realm-name>Jetspeed</realm-name>
+ <form-login-config>
+ <form-login-page>/login/login</form-login-page>
+ <form-error-page>/login/error</form-error-page>
+ </form-login-config>
+ </login-config>
+]]></source>
+</li>
+ <li>Remove the servlets: LoginProxyServlet, LoginServlet, LoginErrorServlet, LoginRedirectorServlet and LogoutServlet</li>
+ <li>Remove the servlet-mappings for the above servlets</li>
+ </ul>
+ </ol>
+ </p>
+</subsection>
+<subsection name='Shibboleth'>
+<p>
+Jetspeed comes with a Shibboleth filter for performing Single Sign-on (SSO) with Shibboleth and the Jetspeed Portal.
+ Shibboleth's Service Provider provides HTTP request headers. The filter reads and interprets the Shibboleth headers as single sign-on tokens.
+ Shibboleth can also be configured to provide various user attributes that can be passed onto the portal. Refer to your Shibboleth documentation for more details.
+ The Jetspeed Shiboleth filter is configured in the Jetspeed web.xml:
+</p>
+
+<source><![CDATA[
+<filter>
+ <filter-name>ShibbolethPortalFilter</filter-name>
+ <filter-class>org.apache.jetspeed.security.impl.shibboleth.ShibbolethPortalFilter
+ </filter-class>
+</filter>
+]]></source>
<p>
+If there are no Shibboleth headers present, Jetspeed will not authenticate the user.
+If there are Shibboleth tokens on the HTTP request, Jetspeed will use them and automatically authenticate users,
+ bypassing Jetspeed's internal authentication and login mechanisms.
</p>
+<p>
+To configure Jetspeed to use Shibboleth headers, there is a Spring configuration file found under WEB-INF/assembly/alternate/shibboleth.xml:
+</p>
+
+<source><![CDATA[
+<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
+<bean id="org.apache.jetspeed.security.shibboleth.ShibbolethConfiguration"
+ class="org.apache.jetspeed.security.impl.shibboleth.ShibbolethConfiguration">
+ <!-- map of common jetspeed-security principals to shibboleth headers -->
+ <constructor-arg index='0'>
+ <map>
+ <entry key='username'>
+ <value>shib-person-commonname</value>
+ </entry>
+ </map>
+ </constructor-arg>
+ <!-- Always authenticate against Jetspeed (should be false if your jetspeed db != authentication users) -->
+ <constructor-arg index='1'>
+ <value type="boolean">true</value>
+ </constructor-arg>
+ <constructor-arg index='2'>
+ <ref bean="PortalConfiguration" />
+ </constructor-arg>
+ </bean>
+</beans>
+]]></source>
+
+<p>
+The first constructor argument is a map of common jetspeed security names. Currently we only support mapping the <code>username</code> from a Shibboleth principal. It is configured to map to the Shibboleth header/attribute named <code>sub-person-commonname</code>.
+</p>
+<p>
+The second constructor turns on or off Jetspeed authentication. Turn this off if you simply want to trust Shibboleth or if you don't have passwords available in constructor-arg one.
+</p>
+
+
+</subsection>
</section>
</body>
-</document>
+</document>
\ No newline at end of file
Modified: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/credentials.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/credentials.xml?rev=768082&r1=768081&r2=768082&view=diff
==============================================================================
--- portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/credentials.xml (original)
+++ portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/credentials.xml Thu Apr 23 22:28:35 2009
@@ -24,7 +24,7 @@
</authors>
</properties>
<body>
- <section name="User interaction">
+ <section name="Managing Credentials">
<p>
Although the <code>DefaultCredentialHandler</code> provides fine-grained management of credentials, it cannot
provide direct feedback to the user like presenting a warning that the current password is soon to be expired.
@@ -34,7 +34,7 @@
configuration file.</p>
<subsection name="LoginValidationValveImpl">
<p>
- The <a href="apidocs/org/apache/jetspeed/security/impl/LoginValidationValveImpl.html">
+ The <a href="../multiproject/jetspeed-portal/apidocs/org/apache/jetspeed/security/impl/LoginValidationValveImpl.html">
<code>LoginValidationValveImpl</code></a> provides feedback to the user about the cause of an failed login
attempt.</p>
<p>
@@ -44,7 +44,7 @@
presented to the user.</p>
<p>
The following possible error codes can be returned (all defined in the
- <a href="jetspeed-api/apidocs/org/apache/jetspeed/login/LoginConstants.html">
+ <a href="../multiproject/jetspeed-api/apidocs/org/apache/jetspeed/login/LoginConstants.html">
<code>LoginConstants</code></a> interface):</p>
<ol>
<li>ERROR_UNKNOWN_USER</li>
@@ -77,7 +77,7 @@
</subsection>
<subsection name="PasswordCredentialValveImpl">
<p>
- The <a href="jetspeed-portal/apidocs/org/apache/jetspeed/security/impl/PasswordCredentialValveImpl.html">
+ The <a href="../multiproject/jetspeed-portal/apidocs/org/apache/jetspeed/security/impl/PasswordCredentialValveImpl.html">
<code>PasswordCredentialValveImpl</code></a> is meant to be used together with a special Portlet on a
special Portal Page (PSML) to automatically request or even require a user to change its password.</p>
<p>
@@ -114,7 +114,7 @@
<p>
To be able to automatically provide the user with this information and allow or require the password to
be changed directly after login, a special <code>ProfileLocator</code>
- <a href="jetspeed-api/apidocs/org/apache/jetspeed/profiler/ProfileLocator.html#SECURITY_LOCATOR">
+ <a href="../multiproject/jetspeed-api/apidocs/org/apache/jetspeed/profiler/ProfileLocator.html#SECURITY_LOCATOR">
<code>SECURITY_LOCATOR</code></a> is used. The <code>PageProfilerValve</code> (which should be configed
<em>after</em> this valve in the pipeline) will then use this enforced locator to be used to find the
related portal page to present to the user.</p>
@@ -122,7 +122,7 @@
For this to work, a <code>"security"</code> Profiler rule must have been setup like the default one
provided by Jetspeed:</p>
<p align="center">
- <img src="deployguide/images/security-locator.jpg" border="0"/>
+ <img src="../deployguide/images/security-locator.jpg" border="0"/>
</p>
<p>
As can seen from the above image, the default page which will be presented to the user is the
@@ -133,7 +133,7 @@
<p>
The <code>ChangePasswordPortlet</code> works together with the <code>PasswordCredentialValveImpl</code>
as it checks for the
- <a href="jetspeed-api/apidocs/org/apache/jetspeed/security/PasswordCredential.html#PASSWORD_CREDENTIAL_DAYS_VALID_REQUEST_ATTR_KEY">
+ <a href="../multiproject/jetspeed-api/apidocs/org/apache/jetspeed/security/PasswordCredential.html#PASSWORD_CREDENTIAL_DAYS_VALID_REQUEST_ATTR_KEY">
<code>PASSWORD_CREDENTIAL_DAYS_VALID_REQUEST_ATTR_KEY</code></a> request parameter which will be set by
this valve with the number of days the password is still valid. For a required password change this will
be set to Integer(0).</p>
Modified: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/deploy-tools.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/deploy-tools.xml?rev=768082&r1=768081&r2=768082&view=diff
==============================================================================
--- portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/deploy-tools.xml (original)
+++ portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/deploy-tools.xml Thu Apr 23 22:28:35 2009
@@ -23,27 +23,27 @@
</authors>
</properties>
<body>
- <section name="The Role of Jetspeed-2 Deploy Tools">
+ <section name="The Role of Jetspeed Deploy Tools">
<subsection name="JetspeedDeploy and the DeploymentManager">
<p>
- <code>JetspeedDeploy</code> prepares portlet applications for deployment within Jetspeed-2. When a new
- portlet deployment event is registered, the <code>DeployPortletAppEventListener</code> invokes <code>JetspeedDeploy</code>
- to prepare the portlet application for deployment.
- <source>
- new JetspeedDeploy(event.getPath(), toFile.getAbsolutePath(), stripLoggers);
- </source>
- </p>
- <p>
- <code>JetspeedDeploy</code> copies the web application archives (.war) from the input directory to the
- output directory and parses the <code>web.xml</code>, <code>portlet.xml</code>, and <code>context.xml</code>
- to ensure their compliance with the Jetspeed-2 portal engine.
+ The Jetpeed Deployment tool (JetspeedDeploy) prepares portlet applications for deployment within the Jetspeed Portal. Jetspeed requires
+ that a servlet be added to all portlet application's web.xml declarations before the portlet application can be run with Jetpeed.
+ Your portlet application can be prepared for deployment by you manually editing the web.xml and adding the required servlet, or the tool
+ can be used standalone, from the command line. Or, you can also rely on Jetspeed to add the servlet itself, as the deploy tool is built
+ into the Jetspeed Portal itself. Inside the portal, when a new
+ portlet deployment event is registered, the <code>DeployPortletAppEventListener</code> invokes <code>JetspeedDeploy</code> tool
+ to prepare the portlet application for deployment. When are new events registered? When you drop the portlet application WAR in the deploy
+ directory, which is located by default in the Jetspeed WEB-INF/deploy directory.
+ <code>JetspeedDeploy</code> copies the web application archives (.war) from the WEB-INF/deploy directory to the
+ destination directory (for example, the Tomcat /webapps directory) and parses the <code>web.xml</code>, <code>portlet.xml</code>, and <code>context.xml</code>
+ to ensure their compliance with the Jetspeed-2 portal engine.
</p>
<p>
- <img src="deployguide/images/jetspeed-deploy-c.gif" border="0"/><br/><br/>
+ <img src="images/jetspeed-deploy-c.gif" border="0"/><br/><br/>
</p>
<p>
- <code>JetspeedDeploy</code> invokes the <code>JetspeedWebApplicationRewriter</code> to infuse the <code>web.xml</code>
- with the <code>JetspeedContainer</code> servlet if it does not already exist:
+ The deploy tool then infuses the <code>web.xml</code>
+ with the <code>JetspeedContainer</code> servlet if it does not already exist, which is necessary for any portlet application deployed to Jetpeed:
<source>
<servlet>
<servlet-name>JetspeedContainer</servlet-name>
@@ -66,7 +66,7 @@
<p>
In the same fashion, the <code>JetspeedDeploy</code> invokes the <code>JetspeedContextRewriter</code> to manipulate
a portlet application <code>context.xml</code> file. For more information about Tomcat <code>context.xml</code>,
- see <a href="http://tomcat.apache.org/tomcat-5.0-doc/deployer-howto.html#Context%20descriptors">tomcat's documentation</a>.
+ see <a href="http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html#A%20word%20on%20Contexts">tomcat's documentation</a>.
</p>
</subsection>
<subsection name="JetspeedDeploy Standalone Usage">
Modified: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/deploying-jetspeed-to-websphere.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/deploying-jetspeed-to-websphere.xml?rev=768082&r1=768081&r2=768082&view=diff
==============================================================================
--- portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/deploying-jetspeed-to-websphere.xml (original)
+++ portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/deploying-jetspeed-to-websphere.xml Thu Apr 23 22:28:35 2009
@@ -584,7 +584,7 @@
<subsection name='Remove any old shared libraries'>
<p>
<a name="section_5_3"></a>
- If you deploy the shared jar files into your EAR file, you will want to remove any application server-wide shared libraries such as the one configured in <a href="section_43">section 4.3</a> #Add a Shared Library Reference to the Application Server Class Loader.
+ If you deploy the shared jar files into your EAR file, you will want to remove any application server-wide shared libraries such as the one configured in <a href="#section_4_3">section 4.3</a> #Add a Shared Library Reference to the Application Server Class Loader.
</p>
</subsection>
<subsection name='Installing the EAR File'>
Modified: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/distributed-cache.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/distributed-cache.xml?rev=768082&r1=768081&r2=768082&view=diff
==============================================================================
--- portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/distributed-cache.xml (original)
+++ portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/distributed-cache.xml Thu Apr 23 22:28:35 2009
@@ -24,76 +24,285 @@
</authors>
</properties>
<body>
- <section name="Jetspeed Distributed Cache">
-First, verify that the following page-manager test works on your development machine:
-
-mvn test -P test -Dtest=TestDatabasePageManagerCache
-
-Not only must this test pass, but the following message should not appear in the
-console/shell or in the test log files:
-
-"Server page managers not distributed: possible system limitation... test skipped"
+<section name="Jetspeed Distributed Cache Configuration">
+ <p>
+ Jetspeed can be optionally configured to use distributed cache replication with ehcache.
+ By default, distributed cache replication is disabled but it can be enabled through the Jetspeed configuration.
+ The assembly folder contains <strong><code>cache.xml</code></strong> to control the ehcache configuration via Spring.
+ </p>
+ <p>
+ Jetspeed uses cache-replication for managing all of its distributed caches, such as the page-manager and preferences caches.
+ The <strong><code>ehcache.xml</code></strong> (found in <strong><code>/WEB-INF/classes/</code></strong>) has more detailed cache configuration details.
+ It has been modified to enable distributed cache replication for all caches including the page manager and preferences caches.
+ </p>
+ <p>
+ The following examples are taken from the <strong><code>distributed-ehcache.xml</code></strong> (in <strong><code>/WEB-INF/classes/</code></strong>).
+ If you want to switch to complete distributed cache usage, it is easier to swap the usages of <strong><code>ehache.xml</code></strong> with
+ the <strong><code>distributed.ehcache.xml</code></strong> completely in <strong><code>cache.xml</code></strong> (in <strong><code>/WEB-INF/assembly/</code></strong>) as shown below.
+ </p>
+ <p>
+<source><![CDATA[
+<!-- Cache Manager -->
+<bean id="cacheManagerConfig" class="org.apache.jetspeed.cache.impl.EhCacheConfigResource">
+ <!-- <property name="defaultConfigResource" value="distributed-ehcache.xml"/> -->
+ <property name="defaultConfigResource" value="ehcache.xml"/>
+</bean>
+]]></source>
+ </p>
+ <p>
+ The Listener and Provider factory caches are required for cache replication. You shouldn't have to enter values in this file but instead use the jetspeed override.properties to set them.
+ Below are parameters which can be set for configuring the distributed cache.
+ The port and hostname can be the same for all nodes in the cluster under most default configurations.
+ </p>
-If you see the above message, check firewall settings to allow UDP/4446. That is
-sometimes needed on Lunix systems if firewalls are enabled to allow udp multicast
-loopback. Some older TCP stacks do not support udp multicast loopback at all. This
-is why this test does not outright fail when distributed caches can not be setup.
-
-Now for the full test: setup two independent tomcat J2 images.
-
-
-Edit webapps/jetspeed/WEB-INF/assembly/cache.xml in tomcat image #1:
-<source><![CDATA[
- <bean id="cacheManagerConfig" class="org.apache.jetspeed.cache.impl.EhCacheConfigResource">
- <property name="defaultConfigResource" value="distributed-ehcache.xml"/>
- <property name="defaultHostname" value="localhost"/>
- <property name="defaultPort" value="40001"/>
- </bean>
-]]></source>
-Edit webapps/jetspeed/WEB-INF/assembly/cache.xml in tomcat image #2:
-<source><![CDATA[
- <bean id="cacheManagerConfig" class="org.apache.jetspeed.cache.impl.EhCacheConfigResource">
- <property name="defaultConfigResource" value="distributed-ehcache.xml"/>
- <property name="defaultHostname" value="localhost"/>
- <property name="defaultPort" value="40002"/>
- </bean>
-]]></source>
-Startup browsers against each server, (remember to use different host names to
-ensure cookies are managed separately... for instance: '127.0.0.1' and 'localhost').
-View the same page in each browser. Edit the page in one browser. Change should be
-visible in second browser on refresh.
-
-When distributed caches are run on multiple virtual or physical servers, the default
-port assigned above does not need to be incremented for each machine. If the servers
-are deployed on multiple networks, care must be taken to ensure multicast traffic on
-UDP/4446/230.0.0.1 and TCP/40001 is routed between the servers. Additionally,
-multicast propagation TTL may have to be specified to enable the UDP packets to
-jump between networks. The default value is "1", which is supposed to limit packets
-to one subnet. Here are the ttl options:
-
- 0 - the same host
- 1 - the same subnet
- 32 - the same site
- 64 - the same region
- 128 - the same continent
- 255 - unrestricted
-
-Here is a fully specified cacheManagerConfig bean with its distributed cache default
-values for normal installation:
-<source><![CDATA[
-
- <bean id="cacheManagerConfig" class="org.apache.jetspeed.cache.impl.EhCacheConfigResource">
- <property name="defaultConfigResource" value="distributed-ehcache.xml"/>
- <property name="defaultGroupAddress" value="230.0.0.1"/>
- <property name="defaultGroupPort" value="4446"/>
- <property name="defaultGroupTTL" value="1"/>
- <property name="defaultHostname" value="localhost"/>
- <property name="defaultPort" value="40001"/>
- </bean>
+ <subsection name="ListenerFactory">
+ <p>
+<source><![CDATA[
+<cacheManagerPeerListenerFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory"
+ properties="hostName=${org.apache.jetspeed.ehcache.hostname},
+ port=${org.apache.jetspeed.ehcache.port}"/>
]]></source>
+ </p>
+ </subsection>
+
+ <subsection name="ProviderFactory">
+ <p>
+<source><![CDATA[
+<cacheManagerPeerProviderFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
+ properties="peerDiscovery=automatic,
+ multicastGroupAddress=${org.apache.jetspeed.ehcache.group.address},
+ multicastGroupPort=${org.apache.jetspeed.ehcache.group.port},
+ timeToLive=${org.apache.jetspeed.ehcache.group.ttl}"/>
+]]></source>
+ </p>
+ </subsection>
+
+ <subsection name="preferencesCache">
+ <p>
+<source><![CDATA[
+<cache name="preferencesCache"
+ maxElementsInMemory="10000"
+ maxElementsOnDisk="1000"
+ eternal="false"
+ overflowToDisk="false"
+ timeToIdleSeconds="28800"
+ timeToLiveSeconds="28800"
+ memoryStoreEvictionPolicy="LFU">
+ <cacheEventListenerFactory
+ class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
+ properties="replicateAsynchronously=true, replicatePuts=false,
+ replicateUpdates=false, replicateUpdatesViaCopy=false,
+ replicateRemovals=true"/>
+ </cache>
+]]></source>
+ </p>
+ </subsection>
+
+ <subsection name="pageManagerPathCache">
+ <p>
+<source><![CDATA[
+<cache name="pageManagerPathCache"
+ maxElementsInMemory="${org.apache.jetspeed.ehcache.pagemanager.maxelements}"
+ eternal="false"
+ overflowToDisk="false"
+ timeToIdleSeconds="${org.apache.jetspeed.ehcache.pagemanager.element.ttl}"
+ timeToLiveSeconds="${org.apache.jetspeed.ehcache.pagemanager.element.ttl}"
+ memoryStoreEvictionPolicy="LFU">
+ <cacheEventListenerFactory class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
+ properties="replicateAsynchronously=true,
+ replicatePuts=false,
+ replicateUpdates=false,
+ replicateUpdatesViaCopy=false,
+ replicateRemovals=true"/>
+</cache>
+]]></source>
+ </p>
+ </subsection>
+ <subsection name='Hostnames'>
+ <p>
+ The host name, represented by the <code>org.apache.jetspeed.ehcache.hostname</code> property, is the host the listener is running on.
+ The host name defaults to the host name of the default interface if not specified.
+ You will be required to specify a host name for each node when the host is multi-homed and you want to control the interface over which cluster messages are received.
+ For instance, if you happen to setup your network so that the cache to cache communication is not on the default interface, then you have to set that host name property on each machine.
+ This requires a custom jetspeed.property file for each node.
+ </p>
+ <p>Configuring a different hostname per node can be done through the Cache Manager configuration Spring bean combined with setting a Java System property.
+ In the <code>cache.xml</code>, you can configure the <code>CacheManagerConfig</code> to use a system property, in this case a property named <code>server.ref</code>.
+ This argument is populated at runtime in the portal framework via the following setting in cache.xml:</p>
+<source><![CDATA[
+ <!-- Cache Manager -->
+ <bean id="cacheManagerConfig" class="org.apache.jetspeed.cache.impl.EhCacheConfigResource">
+ <!-- <property name="defaultConfigResource" value="distributed-ehcache.xml"/> -->
+ <property name="defaultConfigResource" value="ehcache${server.ref}.xml"/>
+ </bean>
+]]></source>
+ <p>Make sure to set the system property, for example at startup:</p>
+<source><![CDATA[
+java .... -Dserver.ref=_NODE56
+]]></source>
+ </subsection>
+ <subsection name='Cache Properties'>
+ <p>
+ Following are the default settings for using the distributed cache. These can be set/modified in the <strong><code>jetspeed.properties</code></strong> or <strong><code>override.properties</code></strong>:
+ </p>
+
+ <table>
+ <tr>
+ <th colspan="3">Cache (commented out by default)</th>
+ </tr>
+ <tr>
+ <td colspan="3">Cache page manager override properties.</td>
+ </tr>
+ <tr>
+ <th>Property</th>
+ <th>Default</th>
+ <th>Description</th>
+ </tr>
+ <tr>
+ <td>#org.apache.jetspeed.ehcache.pagemanager.maxelements</td>
+ <td>128</td>
+ <td>Database page manager cache size</td>
+ </tr>
+ <tr>
+ <td>#org.apache.jetspeed.ehcache.pagemanager.element.ttl</td>
+ <td>150</td>
+ <td>Database page manager cache element expiration in seconds, (infinite = 0)</td>
+ </tr>
+ <tr>
+ <td>#org.apache.jetspeed.ehcache.pagemanager.maxfiles</td>
+ <td>1000</td>
+ <td>PSML page manager file cache size</td>
+ </tr>
+ <tr>
+ <td>#org.apache.jetspeed.ehcache.config.resource</td>
+ <td>ehcache.xml</td>
+ <td>Cache configuration resource, ('ehcache.xml' or 'distributed-ehcache.xml' supported by default)</td>
+ </tr>
+ <tr>
+ <td>#org.apache.jetspeed.ehcache.group.address</td>
+ <td>230.0.0.1</td>
+ <td>Distributed cache peer discovery multicast address</td>
+ </tr>
+ <tr>
+ <td>#org.apache.jetspeed.ehcache.group.port</td>
+ <td>4446</td>
+ <td>Distributed cache peer discovery multicast port</td>
+ </tr>
+ <tr>
+ <td>#org.apache.jetspeed.ehcache.group.ttl</td>
+ <td>1</td>
+ <td>Distributed cache peer discovery multicast TTL. Choose based on the nodes locations.
+ <ul>
+ <li>0 - restricted to the same host</li>
+ <li>1 - restricted to the same subnet</li>
+ <li>32 - restricted to the same site</li>
+ <li>64 - restricted to the same region</li>
+ <li>128 - restricted to the same continent</li>
+ <li>255 - unrestricted</li>
+ </ul>
+ </td>
+ </tr>
+ <tr>
+ <td>#org.apache.jetspeed.ehcache.hostname</td>
+ <td></td>
+ <td>Distributed cache peer hostname, (set to listen on specific interface). Hostname will need to be entered for every node in some cases, see section above on <code>Hostnames</code>, otherwise leave blank.</td>
+ </tr>
+ <tr>
+ <td>#org.apache.jetspeed.ehcache.port</td>
+ <td>40001</td>
+ <td>Distributed cache peer port. Port should be different for each node if they are running on the same machine.</td>
+ </tr>
+ </table><br/>
+
+ <p>
+ These settings are specific for the page manger cache:<br />
+ <ul>
+ <li>#org.apache.jetspeed.ehcache.pagemanager.maxelements=128</li>
+ <li>#org.apache.jetspeed.ehcache.pagemanager.element.ttl=150</li>
+ <li>#org.apache.jetspeed.ehcache.pagemanager.maxfiles=1000</li>
+ </ul>
+ </p>
+ </subsection>
+</section>
-Any of these can be configured to reflect requirements of the production network.
+<section name="Testing Jetspeed Distributed Cache">
+ <p>
+ First, verify that the following page-manager test works on your development machine:
+ </p>
+ <p>
+<source><![CDATA[
+mvn test -P test -Dtest=TestDatabasePageManagerCache
+]]></source>
+ </p>
+ <p>
+ Not only must this test pass, but the following message should not appear in the
+ console/shell or in the test log files:
+ </p>
+ <p><strong>
+ "Server page managers not distributed: possible system limitation... test skipped"
+ </strong></p>
+ <p>
+ If you see the above message, check firewall settings to allow UDP/4446. That is
+ sometimes needed on Lunix systems if firewalls are enabled to allow UDP multicast
+ loopback. Some older TCP stacks do not support UDP multicast loopback at all. This
+ is why this test does not outright fail even though distributed caches can not be setup.
+ </p>
+ <p>
+ Now for the full test: setup two independent tomcat J2 images.
+ Edit <strong><code>webapps/jetspeed/WEB-INF/assembly/cache.xml</code></strong> for Tomcat image #1:
+ </p>
+<source><![CDATA[
+<bean id="cacheManagerConfig" class="org.apache.jetspeed.cache.impl.EhCacheConfigResource">
+ <property name="defaultConfigResource" value="distributed-ehcache.xml"/>
+ <property name="defaultHostname" value="localhost"/>
+ <property name="defaultPort" value="40001"/>
+</bean>
+]]></source>
+ <p>
+ Edit <strong><code>webapps/jetspeed/WEB-INF/assembly/cache.xml</code></strong> for Tomcat image #2:
+ </p>
+<source><![CDATA[
+<bean id="cacheManagerConfig" class="org.apache.jetspeed.cache.impl.EhCacheConfigResource">
+ <property name="defaultConfigResource" value="distributed-ehcache.xml"/>
+ <property name="defaultHostname" value="localhost"/>
+ <property name="defaultPort" value="40002"/>
+</bean>
+]]></source>
+
+ <p>
+ Startup browsers against each server. Use different host names to
+ ensure cookies are managed separately (i.e. '127.0.0.1' and 'localhost').
+ View the same page in each browser. Edit the page in one browser. Upon refresh, changes should be
+ visible in second browser.
+ </p>
+ <p>
+ When distributed caches are run on multiple virtual or physical servers, the default
+ port assigned above does not need to be incremented for each machine. If the servers
+ are deployed on multiple networks, care must be taken to ensure multicast traffic on
+ UDP/4446/230.0.0.1 and TCP/40001 is routed between the servers. Additionally,
+ multicast propagation TTL may have to be specified to enable the UDP packets to
+ jump between networks. The default value is "1", which is supposed to limit packets
+ to one subnet. (See the org.apache.jetspeed.ehcache.group.ttl property).
+ </p>
+ <p>
+ Here is a fully specified cacheManagerConfig bean with its distributed cache default
+ values for normal installation:
+ </p>
+<source><![CDATA[
+<bean id="cacheManagerConfig" class="org.apache.jetspeed.cache.impl.EhCacheConfigResource">
+ <property name="defaultConfigResource" value="distributed-ehcache.xml"/>
+ <property name="defaultGroupAddress" value="230.0.0.1"/>
+ <property name="defaultGroupPort" value="4446"/>
+ <property name="defaultGroupTTL" value="1"/>
+ <property name="defaultHostname" value="localhost"/>
+ <property name="defaultPort" value="40001"/>
+</bean>
+]]></source>
+ <p>
+ Any of these can be configured to reflect requirements of the production network.
+ </p>
</section>
+
</body>
</document>
Modified: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-aggregation.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-aggregation.xml?rev=768082&r1=768081&r2=768082&view=diff
==============================================================================
--- portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-aggregation.xml (original)
+++ portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-aggregation.xml Thu Apr 23 22:28:35 2009
@@ -124,6 +124,12 @@
and represents the timeout value that Jetspeed will give the portlet to complete
rendering before it gives up.
</p>
+ <p>
+ IMPORTANT: This parameter serves two purposes: (1) the presence of it enables parallel rendering for a portlet, and (2) the value determines how long Jetspeed will
+give this portlet to complete rendering before it times out and abandons rendering the portlet. Future versions will relax the first requirement. Beware that even if parallel
+rendering is enabled, portlets will not be rendered outside the main thread group, i.e. in sequential, unless this timeout parameter exists in the jetspeed-portlet.xml.
+ </p>
+
<source test="">
<![CDATA[
<portlet>
Added: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-caching.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-caching.xml?rev=768082&view=auto
==============================================================================
--- portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-caching.xml (added)
+++ portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-caching.xml Thu Apr 23 22:28:35 2009
@@ -0,0 +1,204 @@
+<?xml version="1.0"?>
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<document>
+ <properties>
+ <title>Portlet Caching</title>
+ <subtitle>Portlet Caching</subtitle>
+ <authors>
+ <person name="David Sean Taylor" email="taylor@apache.org" />
+ </authors>
+ </properties>
+ <body>
+ <section name="Portlet Expiration Caching">
+ <p>
+ The Expiration Cache for specific portlets is declared in your portlet.xml deployment descriptor.
+ At runtime, you can also modify the cache in the <a href='../adminguide/pam.html'>Registry admin</a> for your portlet.
+ Caching content helps improve the Portal response time for users. An expiration
+ mechanism is provided on a per portlet basis. Be careful with this feature as cached content, in the Portlet 1.0 specification, the cache is not shared across users.
+ Each user will receive their own cached content. This feature can use up a lot of memory when you have thousands of users.
+ The real advantage to using portlet caching is when you have content that is very expensive, performance-wise, to produce.
+ </p>
+ <p>
+ Expiration times are defined in the portlet.xml and are specified in seconds:
+<source><![CDATA[
+<portlet>
+ <expiration-cache>300</expiration-cache>
+</portlet>
+]]></source>
+ <ul>
+ <li>A value of 0 indicates information is never cached.</li>
+ <li>A value of -1 indicates the cache never expires.</li>
+ </ul>
+ </p>
+
+ <subsection name="Jetspeed Caches">
+ <p>The Jetspeed portal maintains its several system caches to increase portal performance. These caches can be made <a href='distributed-cache.html'>distributed</a>, but n the default deployment, they are not distributed.
+ The <code>ehcache.xml</code> file, found under <code>WEB-INF/classes</code>, configures the Jetspeed system caches.
+ </p>
+ <p>
+<table>
+ <tr>
+ <th colspan="3">Jetspeed Caches</th>
+ </tr>
+ <tr>
+ <th>Cache</th>
+ <th>Description</th>
+ <th>Parameters</th>
+ </tr>
+ <tr>
+ <td>portletContentCache</td>
+ <td>JSR-168 Portlet Content Cache
+ This cache implements the JSR-168 caching specification (see Portlet Expiration Caching above).
+ The timeToIdle and timeToLive are set to defaults here, but are
+ always overriden on a per cache-element basis based on the portlet deployment
+ descriptor value. If there are more than 10000 elements it will not by default, overflow to the
+ disk cache, which in this configuration will go to wherever java.io.tmp is
+ defined on your system. On a standard Linux system this will be /tmp
+ timeToIdleSeconds and timeToLiveSeconds to live are both set at 8 hours (28800)
+ this is the default setting for portlets who set their expiration cache as -1
+ </td>
+ <td>10,000 elements, time to idle/live = 8 hours, overflow to disk = false, LFU</td>
+ </tr>
+ <tr>
+ <td>preferencesCache</td>
+ <td>Caches all preference nodes as elements, including user and default preferences. A single user preference can be represented by as many as 8 nodes in memory per user. When calculating
+ your cache size, also consider the default preferences along with the per user preferences requirements. Also see the section below on <code>Preferences Cache Preloading</code> for instructions on preloading the preferences cache.</td>
+ <td>10,000 elements, time to idle/live = 8 hours, overflow to disk = false, LFU</td>
+ </tr>
+ <tr>
+ <td>portletApplicationNameCache</td>
+ <td>Portlet Applications are cached by application name. This cache is hooked into the object-relational database cache and is essential for reasonable performance of the portal.</td>
+ <td>500 elements, time to idle/live = 8 hours, overflow to disk = false, LFU</td>
+ </tr>
+ <tr>
+ <td>portletApplicationOidCache</td>
+ <td>Portlet Applications are cached by object id. This cache is hooked into the object-relational database cache and is essential for reasonable performance of the portal.</td>
+ <td>500 elements, time to idle/live = 8 hours, overflow to disk = false, LFU</td>
+ </tr>
+ <tr>
+ <td>portletDefinitionNameCache</td>
+ <td>Portlet Definition are cached by portlet unique name. This cache is hooked into the object-relational database cache and is essential for reasonable performance of the portal.</td>
+ <td>2000 elements, time to idle/live = 8 hours, overflow to disk = false, LFU</td>
+ </tr>
+ <tr>
+ <td>portletDefinitionOidCache</td>
+ <td>Portlet Definition are cached by object id. This cache is hooked into the object-relational database cache and is essential for reasonable performance of the portal.</td>
+ <td>2000 elements, time to idle/live = 8 hours, overflow to disk = false, LFU</td>
+ </tr>
+ <tr>
+ <td>decorationConfigurationCache</td>
+ <td></td>
+ <td>500 elements, time to idle/live = 8 hours, overflow to disk = false, LFU</td>
+ </tr>
+ <tr>
+ <td>portletWindowCache</td>
+ <td>Caches portlet window accessor objects to speed up access for portlet fragment to window lookups</td>
+ <td>200 elements, time to idle/live = 8 hours, overflow to disk = false, LFU</td>
+ </tr>
+ <tr>
+ <td>pageManagerOidCache</td>
+ <td>Pages are cached by object id. This cache is hooked into the object-relational database cache and is essential for reasonable performance of the portal.</td>
+ <td>128 elements, time to idle/live = 150 seconds, overflow to disk = false, LFU</td>
+ </tr>
+ <tr>
+ <td>pageManagerPathCache</td>
+ <td>Pages are cached by the page full path. This cache is hooked into the object-relational database cache and is essential for reasonable performance of the portal.</td>
+ <td>128 elements, time to idle/live = 150 seconds, overflow to disk = false, LFU</td>
+ </tr>
+</table>
+</p>
+
+ <p>
+<table>
+ <tr>
+ <th colspan="2">General Cache Settings in ehcache.xml</th>
+ </tr>
+ <tr>
+ <th>Setting</th>
+ <th>Description</th>
+ </tr>
+ <tr>
+ <td>maxElementsInMemory</td>
+ <td>Sets the maximum number of objects that will be created in memory</td>
+ </tr>
+ <tr>
+ <td>maxElementsOnDisk</td>
+ <td>Sets the maximum number of objects that will be maintained in the DiskStore
+ The default value is zero, meaning unlimited.</td>
+ </tr>
+ <tr>
+ <td>eternal</td>
+ <td> Sets whether elements are eternal. If eternal, timeouts are ignored and the
+ element is never expired.</td>
+ </tr>
+ <tr>
+ <td>overflowToDisk</td>
+ <td>Sets whether elements can overflow to disk when the memory store
+ has reached the maxInMemory limit.</td>
+ </tr>
+ <tr>
+ <td>timeToIdleSeconds (optional)</td>
+ <td> Sets the time to idle for an element before it expires.
+ i.e. The maximum amount of time between accesses before an element expires
+ Is only used if the element is not eternal.
+ Optional attribute. A value of 0 means that an Element can idle for infinity.
+ The default value is 0.</td>
+ </tr>
+ <tr>
+ <td>timeToLiveSeconds (optional)</td>
+ <td>Sets the time to live for an element before it expires.
+ i.e. The maximum time between creation time and when an element expires.
+ Is only used if the element is not eternal.
+ Optional attribute. A value of 0 means that and Element can live for infinity.
+ The default value is 0.</td>
+ </tr>
+ <tr>
+ <td>memoryStoreEvictionPolicy</td>
+ <td>Policy would be enforced upon reaching the maxElementsInMemory limit. Default
+ policy is Least Recently Used (specified as LRU). Other policies available -
+ First In First Out (specified as FIFO) and Less Frequently Used
+ (specified as LFU)</td>
+ </tr>
+ </table>
+ </p>
+
+ </subsection>
+ <subsection name='Preferences Cache Preloading'>
+ <p>To help with preferences performance, preferences can be preloaded at system started. See the Spring configuration file <code>prefs.xml</code> to modify the loading
+ of preferences into the preference cache at Jetspeed startup. Both default and user (entity) preferences can be optionally preloaded. The default setting is to
+ preload all all preferences for the j2-admin portlet application. See the constructor argument 2 on the <code>PreferencesProviderImpl</code> service, to modify the
+ list of portlet applications default preferences to preload. Leave the list empty to not preload default preferences. The third constructor argument determines
+ whether all user (entity) preferences are preloaded or not. The default is to not preload. Be very careful with this setting as it can result in quickly running out
+ of memory at startup.
+ </p>
+
+<source><![CDATA[
+ <!-- list of portlet applications default preferences to preload, leave list empty to not preload -->
+ <constructor-arg index='2'>
+ <list>
+ <value>j2-admin</value>
+ </list>
+ </constructor-arg>
+ <!-- preload ALL Entities: warning this can chew up lots of memory -->
+ <constructor-arg index='3'><value type="boolean">false</value></constructor-arg>
+]]></source>
+
+ </subsection>
+ </section>
+ </body>
+</document>
Propchange: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-caching.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-caching.xml
------------------------------------------------------------------------------
svn:keywords = Id
Added: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-device-capabilities.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-device-capabilities.xml?rev=768082&view=auto
==============================================================================
--- portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-device-capabilities.xml (added)
+++ portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-device-capabilities.xml Thu Apr 23 22:28:35 2009
@@ -0,0 +1,113 @@
+<?xml version="1.0"?>
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<document>
+ <properties>
+ <title>Jetspeed 2 Device Capabilities</title>
+ <subtitle>Guide to Jetspeed Device Capabilities</subtitle>
+ <authors>
+ <person name="David Sean Taylor" email="taylor@apache.org" />
+ </authors>
+ </properties>
+ <body>
+ <section name="Device Capabilities">
+ <p>
+ Jetspeed capabilities provides a mechanism for mapping the client
+ (browser) used to access the portal to media types for page rendering.
+ </p>
+ <p>
+ A device is associated with a list of capabilities, allowing the portal
+ to know what kind of content the device can handle (such as
+ Javascript, DHTML..)
+ </p>
+ <p>
+ The rules for mapping devices to media types and capabilities are
+ stored in the database. The original values for these are first populated with
+ XML data.
+ </p>
+ <p>
+ Your custom build should be setup with the default XML data for
+ devices and media types. Currently there is no administrative portlets for editing device information.
+ </p>
+ <p>
+ A full set of capabilities, devices, media types and mime types are
+ supplied with the XML test data.
+ </p>
+ <p>
+ The Jetspeed-2 capability engine maps clients to media types to
+ mime types. Here are some more detailed definitions:
+ <ul>
+ <li>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.</li>
+ <li>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.</li>
+ <li>Mime Type: The type of content being requested.</li>
+ <li>Supported Media Types: HTML, XHTML-BASIC, XML, WML, VXML</li>
+ </ul>
+ </p>
+
+ <p>
+Define the default mime types
+<source><![CDATA[
+<MimeTypes>
+ <MimeType>application/xhtml+xml</MimeType>
+ <MimeType>text/html</MimeType>
+ <MimeType>text/vnd.wap.wml</MimeType>
+ <MimeType>text/vxml</MimeType>
+ <MimeType>text/xhtml</MimeType>
+ <MimeType>text/xml</MimeType>
+</MimeTypes>
+]]></source>
+ </p>
+
+ <p>
+Define media types (used in special _control folder processing) and preferred mime type:
+<source><![CDATA[
+<MediaType name="html">
+ <charcterSet value="UTF-8"/>
+ <title value="HTML"/>
+ <description value="Rich HTML for HTML 4.0 compliants browsers"/>
+ <capabilities></capabilities>
+ <mimeTypes>text/html</mimeTypes>
+</MediaType>
+]]></source>
+ </p>
+
+
+ <p>
+Defines supported Clients (browsers) by the portal and their device
+capabilities. Clients are mapped to media types via the preferred
+mime type
+<source><![CDATA[
+<Client name="ie5mac" evalOrder="1" preferredMimeTypeID="text/html">
+ <userAgentPattern value=".*MSIE 5.*Mac.*"/>
+ <version value="5.*"/>
+ <model value="None"/>
+ <manufacturer value="Microsoft"/>
+ <capabilities>
+ HTML_3_2,HTML_JAVA,HTML_JAVASCRIPT, HTML_TABLE,HTML_FORM,HTML_FRAME,HTML_IMAGE,HTML_PLUGIN,HTML_CSS1,HTML_DOM_NS4, HTTP_COOKIE
+ </capabilities>
+ <mimeTypes>text/html</mimeTypes>
+</Client>
+]]></source>
+ </p>
+
+ </section>
+ </body>
+</document>
Propchange: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-device-capabilities.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-device-capabilities.xml
------------------------------------------------------------------------------
svn:keywords = Id
Modified: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-menus-declarative-psml.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-menus-declarative-psml.xml?rev=768082&r1=768081&r2=768082&view=diff
==============================================================================
--- portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-menus-declarative-psml.xml (original)
+++ portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-menus-declarative-psml.xml Thu Apr 23 22:28:35 2009
@@ -27,7 +27,7 @@
<section name="Declarative Menus">
<p>
Declarative menus are used to add new or customize default navigation elements in displayed portal pages.
-These PSML declarations are part of the <a href="guide-psml.html#Page">page</a> and <a href="guide-psml.html#Folder">folder</a> elements.
+These PSML declarations are part of the <a href="../devguide/guide-psml.html#Page">page</a> and <a href="../devguide/guide-psml.html#Folder">folder</a> elements.
As with other PSML elements, effective menu declarations available for a given page are those that are explicity
defined in the page along with all defined in parent folders. For this reason, global site menus are defined in
the PSML associated with the site root folder. Menu definitions in a specific page or folder override
@@ -42,7 +42,7 @@
<ol>
<li>The portal layout decorator would request a menu definition by name,</li>
<li>the definition would be inherited by the current page and located in the root folder PSML,</li>
- <li>the Portal Site Component would interpret the menu definition in the context of the current page and populate <a href="guide-psml.html#Page">page</a>, <a href="guide-psml.html#Folder">folder</a>, and <a href="guide-psml.html#Link">link</a> menu options,</li>
+ <li>the Portal Site Component would interpret the menu definition in the context of the current page and populate <a href="../devguide/guide-psml.html#Page">page</a>, <a href="../devguide/guide-psml.html#Folder">folder</a>, and <a href="../devguide/guide-psml.html#Link">link</a> menu options,</li>
<li>the decorator would display the menu rendering titles and text from the menu definition itself and the computed menu options into portal navigation content.</li>
</ol>
</p>
@@ -69,7 +69,7 @@
</ul>
<li><a href="#Page_Layout_Decorators">Page Layout Decorators</a></li>
<li><a href="#Portal_Site_Component">Portal Site Component</a></li>
- <li><a href="guide-psml-dtd.html#PSML_DTDs">PSML Document DTDs</a></li>
+ <li><a href="../devguide/guide-psml-dtd.html#PSML_DTDs">PSML Document DTDs</a></li>
</ul>
</p>
</section>
@@ -134,7 +134,7 @@
<td>Simple element text specifies default locale-independent short title for the menu. The short title, if available, is used as menu text in some decorators. If not specified, the title text is used.</td>
</tr>
<tr>
- <td><a href="guide-psml.html#PSML_Titles_and_Metadata">metadata</a>*</td>
+ <td><a href="../devguide/guide-psml.html#PSML_Titles_and_Metadata">metadata</a>*</td>
<td>Optionally specifies additional locale-specific titles and short titles.</td>
</tr>
<tr>
@@ -297,7 +297,7 @@
<td>Simple element text specifies default locale-independent text for the separator. The required separator text, whether specified by this attribute or as the contained text of the separator element, is the text to be inserted in the menu by the layout decorator.</td>
</tr>
<tr>
- <td><a href="guide-psml.html#PSML_Titles_and_Metadata">metadata</a>*</td>
+ <td><a href="../devguide/guide-psml.html#PSML_Titles_and_Metadata">metadata</a>*</td>
<td>Optionally specifies additional locale-specific titles and separator text.</td>
</tr>
</table>
@@ -432,13 +432,13 @@
<section name='Portal Site Component'>
<p>
-In conjunction with the <a href="guide-profiler.html">Jetspeed Profiler Component</a>, the Portal Site Component
+In conjunction with the <a href="../devguide/guide-profiler.html">Jetspeed Profiler Component</a>, the Portal Site Component
performs two closely related functions:
<ol>
- <li>Map portal request URLs from a user to PSML <a href="guide-psml.html#Page">page</a> or <a href="guide-psml.html#Folder">folder</a> elements in the site, and</li>
+ <li>Map portal request URLs from a user to PSML <a href="../devguide/guide-psml.html#Page">page</a> or <a href="../devguide/guide-psml.html#Folder">folder</a> elements in the site, and</li>
<li>construct site navigational menus and their options that reflect what is available to the user from the site.</li>
</ol>
-At first glance, these functions seem relatively simple: searching within and traversing the <a href="guide-psml.html">PSML site definition</a>.
+ At first glance, these functions seem relatively simple: searching within and traversing the <a href="../devguide/guide-psml.html">PSML site definition</a>.
However, once the complexities of Profiler composition and <a href="guide-security-declarative-psml.html">Security Constraints</a>
filtering are taken into account, the mapping is often not trivial.
</p>
@@ -464,7 +464,7 @@
<li>security constraints denied access to '/page2.psml' for the user, and</li>
<li>'/hidden-page.psml' is declared hidden in the page PSML.</li>
</ul>
-The current <a href="guide-profiler.html">Profile Locator</a> for the user would specify that the Portal Site Component map the
+The current <a href="../devguide/guide-profiler.html">Profile Locator</a> for the user would specify that the Portal Site Component map the
following portal request URLs to the specific PSML elements:
<table>
<tr>
Modified: portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-ntlm.xml
URL: http://svn.apache.org/viewvc/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-ntlm.xml?rev=768082&r1=768081&r2=768082&view=diff
==============================================================================
--- portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-ntlm.xml (original)
+++ portals/jetspeed-2/portal/branches/JETSPEED-2.1.3-POSTRELEASE/xdocs/deployguide/guide-ntlm.xml Thu Apr 23 22:28:35 2009
@@ -38,7 +38,7 @@
<section name="Configuring NTLM Authentication">
<p>
Jetspeed-2 security configuration is explained
- <a href="guide-security.html">
+ <a href="../devguide/guide-security.html">
here
</a>
.
@@ -83,7 +83,7 @@
The above filters set the correct credentials on the request. To use these credentials, you
have to configure the <code>org.apache.jetspeed.security.impl.ntlm.NtlmSecurityValve</code> in the
Jetspeed pipelines you want to secure. This Valve can be used as a <i>replacement</i> for the default <code>SecurityValveImpl</code>. For explanation about how to set up pipelines, see
- <a href="guide-pipeline.html">here</a>. An example of how to configure the NtlmSecurityValve bean:
+ <a href="guide-pipelines.html">here</a>. An example of how to configure the NtlmSecurityValve bean:
</p>
<source>
<![CDATA[
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org