Page Comparison

...

• Introduction
• Servlet Container Issues
• ample Sample Portlets
• Deploying Portlets
• Publishing Portlets
• Portlet Caching
• User Information
• Portlet Security
• Custom Portlet Modes and Window States
• Future of Portlets in uPortal

...

1. For Tomcat 5, you can include an XML file in the conf/Catalina/{hostname} directory that contains the <Context> element definition. uPortal 2.3 automatically deploys such a file properties/uPortal.xml to conf/Catalina/localhost/uPortal.xml. This, of course, assumes that your context name is uPortal and your hostname is localhost.
2. For Tomcat 4, you can include a similar XML file in the webapps directory.
3. For either Tomcat 4 or 5, you can alternatively edit the conf/server.xml file, adding a <Context> element for your portal application with the crossContext attribute set to true:

   Code Block
   <Context path="/uPortal" docBase="uPortal" crossContext="true"> </Context>

    
   Note: uPortal will not be able to run Portlets in Tomcat 5.0.19 because of a Tomcat bug that is documented here.

...

ant deployPortletApp -DportletApp=all

You can also deploy one Portlet application at a time by specifying the location of the Portlet application WAR file:

ant deployPortletApp -DportletApp=C:/TEMP/myPortlet.war

Publishing Portlets

uPortal will build a Portlet Registry based on all the Portlets that are deployed into the servlet container. It does this by examining all the installed web applications, looking for the ones that contain a portlet.xml file, and parsing that portlet.xml file to find out what Portlet Application Definitions and Portlet Defiinitions are available.

...

Map userInfo = (Map)request.getAttribute(PortletRequest.USER_INFO);
String givenName = (String)userInfo.get("user.name.given");
String lastName = (String)userInfo.get("user.name.last");

The Portlet Specification says that you should be able to map user attribute names declared in the portlet.xml file at deployment time. In uPortal, this feature will not be available. Instead, you will have to edit uPortal's PersonDirs.xml file, adding aliases for any of the user attribute names declared in the portlet.xml file that don't already exist in PersonDirs.xml. Only the attributes defined in portlet.xml will be accessible to your portlet. For example, if your portlet.xml file contains...

<user-attribute>
    <description>User Given Name</description>
    <name>user.name.given</name>
</user-attribute>

...then your PersonDirs.xml will need to contain something like...

<attribute>
    <name>FIRST_NAME</name>
    <alias>user.name.given</alias>
</attribute>

As of uPortal 2.4, Portlets can be configured to receive the user's password as a user attribute. If this is desired, simply include the following user attribute mapping in portlet.xml:

<user-attribute>
    <description>User Password</description>
    <name>password</name>
</user-attribute>

If a password mapping was specified in PersonDirs.xml, then it will be used. Otherwise, uPortal will look for the password in the user's authenticated security contexts that cache credentials, using the first one it finds.

...

<security-role-ref>
    <role-name>myEveryoneRole</role-name>
    <role-link>local.0</role-link>
</security-role-ref>


<security-role-ref>
    <role-name>myStudentRole</role-name>
    <role-link>pags.students</role-link>
</security-role-ref>

If these example mappings were included and the user was authenticated and in the pags.students role, then a call from within the Portlet to portletRequest.isUserInRole("myStudentRole") and portletRequest.isUserInRole("pags.students") should return true.

...