Virtual Hosting

In our Virtual Hosting example, we are hosting three different portal subsites:

Here we have three subsites (four including localhost) defined for three different companies:

• www.company-1.com - the subsite for "Company 1"
• www.company-2.com - the subsite for "Company 2"
• www.company-3.com - the subsite for "Company 3"

Single Organization

In our Single Organization example, we are hosting three different portal subsites within the organization:

Here we have three subsites (four including localhost) defined for three different companies:

• employees.my-company.com - subsite for employees
• partners.my-company.com - subsite for partners
• www.my-company.com - subsite for the public

Site Manager

The screenshots above show using the Site Manager to configure your subsites. The Site Manager is useful for configuring a live site. When you configure a site initially, subsites are configured on the file system as folders, subfolders and pages. Optionally, these folders can be imported in the database. See the Database Page Manager for details on storing subsites in the database.

The Site Manager mirrors your file system (or database structure) in a tree view. Looking at the Site View screenshots above, there are several directories we need to take note of:

• __subsite-root - this is a reserved directory, containing all subsite control roots
• _hostname - this is a control directory (prefixed with underscore) containing all hostname-based subsites

Control directories must always begin with an underscore. Profiling rules navigate through control directories based on runtime parameters. In this example, we are creating subsites based on the hostname runtime parameter

/etc/hosts

Note that the localhost site is there only for developers. Even developers can simulate a virtual hosting environment by editing their /etc/hosts file on their local machines (on Windows under \windows\system32\drivers\etc\hosts) and making fake entries such as:

       
        127.0.0.1 www.company-1.com
        127.0.0.1 www.company-2.com
        127.0.0.1 www.company-3.com

        127.0.0.1 employees.my-company.com
        127.0.0.1 partners.my-company.com
        127.0.0.1 www.my-company.com

Profiling Rules

                
<ProfilingRule id="subsite-by-hostname" standardRule="false">
	<description value="A rule based on role fallback algorithm with specified subsite and home page"/>
	<Criteria>
		<Criterion name="navigation">
			<type value="navigation"/>
			<value value="subsite-root"/>
			<fallBackOrder value="0"/>
			<fallBackType value="2"/>
		</Criterion>
		<Criterion name="hostname">
			<type value="hostname"/>
			<fallBackOrder value="1"/>
			<fallBackType value="2"/>
		</Criterion>
		<Criterion name="user">
			<type value="user"/>
			<fallBackOrder value="2"/>
			<fallBackType value="2"/>
		</Criterion>
		<Criterion name="navigation-2">
			<type value="navigation"/>
			<value value="subsite-root"/>
			<fallBackOrder value="3"/>
			<fallBackType value="2"/>
		</Criterion>
		<Criterion name="hostname-2">
			<type value="hostname"/>
			<fallBackOrder value="4"/>
			<fallBackType value="2"/>
		</Criterion>
		<Criterion name="role">
			<type value="role"/>
			<fallBackOrder value="5"/>
			<fallBackType value="2"/>
		</Criterion>				
		<Criterion name="path">
			<type value="path"/>
			<value value="home"/>
			<fallBackOrder value="6"/>
			<fallBackType value="2"/>
		</Criterion>
	</Criteria>
</ProfilingRule>                               

A profiling rule contains one or more criterion. Each criterion defines an instruction on how to locate a page in the physical portal site map. Criterion of the type navigation are used to navigate down the portal site tree. The fallBackOrder tag should normally just be listed sequential. You can almost always get by with a fallBackType of 2. All of the available criterion types are documented in the online Profiler Guide. The table below describes each criterion in our subsite rule and how it is used in a subsite location algorithm. This rule is a subsite location rule that uses a user-role-fallback algorithm. User-role-fallback algorithms first look for a page in the users home directory. If not found there, they then look for a page in each of the users corresponding role directories. There are other algorithms provided by out of the box such as role-fallback, group-fallback, mediatype/language fallback. Or you can create your own algorithms by creating new profiling rules in the XML seed data or with the Profiler Admininistrative portlet.

The screenshot below shows the directory tree for a localhost subsite.

Notice the _user and _role directories. These are control directories based on the runtime parameters user and role. The user parameter represents the username of the currently logged on user. The role parameter can represent one or more roles of the current user. The subsite algorithm will navigate down to a user directory first, and look in the directory for the current user by name. It will look there for name of the current page requested on the URL. Given the following example runtime parameters, the tables below demonstrates the fallback search path algorthm used by the profiler in locating a page given our subsite profiling rule. Once it finds the page, the page is immediately returned and the algorithm is terminated. For each of the examples below, consider the following runtime parameters:

http://localhost:8080/jetspeed/portal/calendar.psml

http://localhost:8080/jetspeed/portal/accounting/worksheet.psml

http://localhost:8080/jetspeed/portal/

Associated Rules with Users

All users are either explicity or implicity associated with a profiling rule. The User Administration utility has a tab to setup the profiling rule associated with a user:

Additionally, you can associate users with profiling rules in the XML seed data configuration:

                
<Users>
...                
<User name="jetspeed">
	<credentials password="jetspeed" enabled="TRUE" requiresUpdate="FALSE"/>
	<roles>manager</roles>
	<groups>engineering</groups>
	<preferences/>
	<userinfo/>
	<Rules>
		<Rule locator="menu" rule="role-group"/>
		<Rule locator="page" rule="role-fallback"/>
	</Rules>
</User>
</Users>                

Looking at the Rule element of a User, the locator can be either:

• page - use associated profiling rule to locate pages
• menu - use the associated profiling rule to locate menus (if not specified, use the page locator)

The rule attribute on the Rule element of a User defines which profiling rule is associated to either a page or menu locator. If a user is not associated with a locator, then there is a system wide locator configured in the Spring configuration file profiler.xml. See the contructor-arg of index = 1. This locator is the default locator, system-wide, for when there is no-associated profiling rule. Normally, profiling rules are associated with user during activities such as the creation of new users with the User Administration portlet, or during new user registration.

<beans>
    <!-- Profiler -->
    <bean id="profilerImpl" class="org.apache.jetspeed.profiler.impl.JetspeedProfilerImpl" init-method="init">
        <constructor-arg index="0">
            <value>JETSPEED-INF/ojb/profiler_repository.xml</value>
        </constructor-arg>
        <constructor-arg index="1">
            <value>j2</value>
        </constructor-arg>                
        ....