JBoss Portal SVN: r6134 - docs/trunk/referenceGuide/en/modules.
by portal-commits@lists.jboss.org
Author: bdaw
Date: 2007-01-31 18:48:33 -0500 (Wed, 31 Jan 2007)
New Revision: 6134
Modified:
docs/trunk/referenceGuide/en/modules/identity.xml
Log:
some more stuff about identity
Modified: docs/trunk/referenceGuide/en/modules/identity.xml
===================================================================
--- docs/trunk/referenceGuide/en/modules/identity.xml 2007-01-31 15:51:38 UTC (rev 6133)
+++ docs/trunk/referenceGuide/en/modules/identity.xml 2007-01-31 23:48:33 UTC (rev 6134)
@@ -1,29 +1,29 @@
<chapter id="identity">
- <chapterinfo>
- <author>
- <firstname>Boleslaw</firstname>
- <surname>Dawidowicz</surname>
- <email>boleslaw.dawidowicz at jboss dot com</email>
- </author>
- </chapterinfo>
- <title>JBoss Portal Identity management</title>
- <para>This chapter addresses identity management in JBoss Portal 2.6</para>
- <sect1 id="management_api">
- <title>Identity management API</title>
- <para>Since JBoss Portal 2.6 there are 4 identity services and 2 identity related interfaces. The goal of
- having such a fine grained API is to enable flexible implementations based on different
- identity storage like relational databases or LDAP servers. The Membership service takes care of managing the relationship
- between user objects and role objects. The User Profile service is responsible for managing the profile of a user,
- it has database and LDAP implementations as well as a mode that combines data from both.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- The <emphasis role="bold">org.jboss.portal.identity.User</emphasis>
- interface represents a user and exposes the following operations:
- </para>
- <programlisting>
- <![CDATA[
+ <chapterinfo>
+ <author>
+ <firstname>Boleslaw</firstname>
+ <surname>Dawidowicz</surname>
+ <email>boleslaw.dawidowicz at jboss dot com</email>
+ </author>
+ </chapterinfo>
+ <title>JBoss Portal Identity management</title>
+ <para>This chapter addresses identity management in JBoss Portal 2.6</para>
+ <sect1 id="management_api">
+ <title>Identity management API</title>
+ <para>Since JBoss Portal 2.6 there are 4 identity services and 2 identity related interfaces. The goal of
+ having such a fine grained API is to enable flexible implementations based on different
+ identity storage like relational databases or LDAP servers. The Membership service takes care of managing the relationship
+ between user objects and role objects. The User Profile service is responsible for managing the profile of a user,
+ it has database and LDAP implementations as well as a mode that combines data from both.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The <emphasis role="bold">org.jboss.portal.identity.User</emphasis>
+ interface represents a user and exposes the following operations:
+ </para>
+ <programlisting>
+ <![CDATA[
/** The user identifier. */
public Object getId();
@@ -36,11 +36,11 @@
/** Return true if the password is valid. */
public boolean validatePassword(String password);
]]>
- </programlisting>
- <warning>
- Important Note! The proper usage of getId() method is:
- <programlisting>
- <![CDATA[
+ </programlisting>
+ <warning>
+ Important Note! The proper usage of getId() method is:
+ <programlisting>
+ <![CDATA[
// Always use it like this:
user.getId().toString();
@@ -52,19 +52,19 @@
// We would get a String with an LDAP server
(String)user.getId();
]]>
- </programlisting>
- This is because the ID value depends on the User implementation. It'll probably be String object with the LDAP
- implementation and a Long object with the database implementation but it could be something else
- if one has chosen to make its own implementation.
- </warning>
- </listitem>
- <listitem>
- <para>
- The <emphasis role="bold">org.jboss.portal.identity.Role</emphasis> interface represents a Role
- and exposes the following operations:
- </para>
- <programlisting>
- <![CDATA[
+ </programlisting>
+ This is because the ID value depends on the User implementation. It'll probably be String object with the LDAP
+ implementation and a Long object with the database implementation but it could be something else
+ if one has chosen to make its own implementation.
+ </warning>
+ </listitem>
+ <listitem>
+ <para>
+ The <emphasis role="bold">org.jboss.portal.identity.Role</emphasis> interface represents a Role
+ and exposes the following operations:
+ </para>
+ <programlisting>
+ <![CDATA[
/** The role identifier. */
public Object getId();
@@ -77,15 +77,15 @@
/** */
public void setDisplayName(String name);
]]>
- </programlisting>
- </listitem>
- <listitem>
- <para>
- The <emphasis role="bold">org.jboss.portal.identity.UserModule</emphasis>
- interface exposes operations for users management:
- </para>
- <programlisting>
- <![CDATA[
+ </programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ The <emphasis role="bold">org.jboss.portal.identity.UserModule</emphasis>
+ interface exposes operations for users management:
+ </para>
+ <programlisting>
+ <![CDATA[
/**Retrieve a user by its name.*/
User findUserByUserName(String userName) throws IdentityException, IllegalArgumentException, NoSuchUserException;
@@ -110,15 +110,15 @@
/**Returns the number of users.*/
int getUserCount() throws IdentityException, IllegalArgumentException;
]]>
- </programlisting>
- </listitem>
- <listitem>
- <para>
- The <emphasis role="bold">org.jboss.portal.identity.RoleModule</emphasis>
- interface exposes operations for roles management:
- </para>
- <programlisting>
- <![CDATA[
+ </programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ The <emphasis role="bold">org.jboss.portal.identity.RoleModule</emphasis>
+ interface exposes operations for roles management:
+ </para>
+ <programlisting>
+ <![CDATA[
/** Retrieves a role by its name*/
Role findRoleByName(String name) throws IdentityException, IllegalArgumentException;
@@ -165,19 +165,19 @@
/** Get all the roles */
Set findRoles() throws IdentityException;
]]>
- </programlisting>
- </listitem>
- <listitem>
- <para>
- The <emphasis role="bold">MembershipModule</emphasis>
- interface exposes operations for obtaining or managing relationships beetween users and roles.
- The role of this service is to decouple relationship information from user and roles.
- Indeed while user role relationship is pretty straightforward with a relational database (using
- a many to many relationship with an intermediary table), with an LDAP server there a different
- ways to define relationships between users and roles.
- </para>
- <programlisting>
- <![CDATA[
+ </programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ The <emphasis role="bold">MembershipModule</emphasis>
+ interface exposes operations for obtaining or managing relationships beetween users and roles.
+ The role of this service is to decouple relationship information from user and roles.
+ Indeed while user role relationship is pretty straightforward with a relational database (using
+ a many to many relationship with an intermediary table), with an LDAP server there a different
+ ways to define relationships between users and roles.
+ </para>
+ <programlisting>
+ <![CDATA[
/** Return the set of role objects that a given user has.*/
Set getRoles(User user) throws IdentityException, IllegalArgumentException;
@@ -192,15 +192,15 @@
/** Returns role members based on rolename - depreciated method ethod here only for compatibility with old RoleModule interface */
Set findRoleMembers(String roleName, int offset, int limit, String userNameFilter) throws IdentityException, IllegalArgumentException;
]]>
- </programlisting>
- </listitem>
- <listitem>
- <para>
- The <emphasis role="bold">UserProfileModule</emphasis>
- interface exposes operations to access and manage informations stored in User profile:
- </para>
- <programlisting>
- <![CDATA[
+ </programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ The <emphasis role="bold">UserProfileModule</emphasis>
+ interface exposes operations to access and manage informations stored in User profile:
+ </para>
+ <programlisting>
+ <![CDATA[
public Object getProperty(User user, String propertyName) throws IdentityException, IllegalArgumentException;
public void setProperty(User user, String name, Object property) throws IdentityException, IllegalArgumentException;
@@ -209,36 +209,36 @@
public ProfileInfo getProfileInfo() throws IdentityException;
]]>
- </programlisting>
- <warning>
- UserProfileModule.getProperty() method returns an Object.
- In most cases with DB backend it will always be String object. But normally you should check what
- object will be retreived using getProfileInfo() method.
- </warning>
- </listitem>
- <listitem>
- <para>
- The <emphasis role="bold">ProfileInfo</emphasis>
- interface can be obtained using the
- <emphasis role="bold">UserProfileModule</emphasis>
- and exposes meta information of a profile:
- </para>
- <programlisting>
- <![CDATA[
+ </programlisting>
+ <warning>
+ UserProfileModule.getProperty() method returns an Object.
+ In most cases with DB backend it will always be String object. But normally you should check what
+ object will be retreived using getProfileInfo() method.
+ </warning>
+ </listitem>
+ <listitem>
+ <para>
+ The <emphasis role="bold">ProfileInfo</emphasis>
+ interface can be obtained using the
+ <emphasis role="bold">UserProfileModule</emphasis>
+ and exposes meta information of a profile:
+ </para>
+ <programlisting>
+ <![CDATA[
/** Returns a Map o PropertyInfo objects describing profile properties */
public Map getPropertiesInfo();
public PropertyInfo getPropertyInfo(String name);
]]>
- </programlisting>
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">PropertyInfo</emphasis>
- interface expose methods to obtain information about accessible property in User profile
- </para>
- <programlisting>
- <![CDATA[
+ </programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">PropertyInfo</emphasis>
+ interface expose methods to obtain information about accessible property in User profile
+ </para>
+ <programlisting>
+ <![CDATA[
public static final String ACCESS_MODE_READ_ONLY = "read-only";
public static final String ACCESS_MODE_READ_WRITE = "read-write";
public static final String USAGE_MANDATORY = "mandatory";
@@ -268,73 +268,73 @@
public boolean isMappedLDAP();
]]>
- </programlisting>
- </listitem>
+ </programlisting>
+ </listitem>
- </itemizedlist>
+ </itemizedlist>
- <sect2>
- <title>Ways to access identity modules</title>
- <para>
- The best way to access identity modules is by using JNDI:
- </para>
- <programlisting>
- import org.jboss.portal.identity.UserModule;
- import org.jboss.portal.identity.RoleModule;
- import org.jboss.portal.identity.MembershipModule;
- import org.jboss.portal.identity.UserProfileModule;
+ <sect2>
+ <title>Ways to access identity modules</title>
+ <para>
+ The best way to access identity modules is by using JNDI:
+ </para>
+ <programlisting>
+ import org.jboss.portal.identity.UserModule;
+ import org.jboss.portal.identity.RoleModule;
+ import org.jboss.portal.identity.MembershipModule;
+ import org.jboss.portal.identity.UserProfileModule;
- [...]
+ [...]
- (UserModule)new InitialContext().lookup("java:portal/UserModule");
- (RoleModule)new InitialContext().lookup("java:portal/RoleModule");
- (MembershipModule)new InitialContext().lookup("java:portal/MembershipModule");
- (UserProfileModule)new InitialContext().lookup("java:portal/UserProfileModule");
+ (UserModule)new InitialContext().lookup("java:portal/UserModule");
+ (RoleModule)new InitialContext().lookup("java:portal/RoleModule");
+ (MembershipModule)new InitialContext().lookup("java:portal/MembershipModule");
+ (UserProfileModule)new InitialContext().lookup("java:portal/UserProfileModule");
- </programlisting>
- <para>
- Another way to do this is, if you are fimiliar with JBoss Mikrokernel architecture is to
- get the <emphasis role="bold">IdentityServiceController</emphasis>
- mbean. You may want to inject it into your services like this:
- </para>
- <programlisting>
- <![CDATA[<depends optional-attribute-name="IdentityServiceController" proxy-type="attribute">portal:service=Module,type=IdentityServiceController</depends>]]>
- </programlisting>
- <para>
- or simply obtain in your code by doing a lookup using
- the <emphasis role="bold">portal:service=Module,type=IdentityServiceController</emphasis>
- name. Please refer to the JBoss Application Server documentation if you want to learn more
- about service MBeans. Once you obtained the object you can use it:
- </para>
+ </programlisting>
+ <para>
+ Another way to do this is, if you are fimiliar with JBoss Mikrokernel architecture is to
+ get the <emphasis role="bold">IdentityServiceController</emphasis>
+ mbean. You may want to inject it into your services like this:
+ </para>
+ <programlisting>
+ <![CDATA[<depends optional-attribute-name="IdentityServiceController" proxy-type="attribute">portal:service=Module,type=IdentityServiceController</depends>]]>
+ </programlisting>
+ <para>
+ or simply obtain in your code by doing a lookup using
+ the <emphasis role="bold">portal:service=Module,type=IdentityServiceController</emphasis>
+ name. Please refer to the JBoss Application Server documentation if you want to learn more
+ about service MBeans. Once you obtained the object you can use it:
+ </para>
- <programlisting>
- (UserModule)identityServiceController.getIdentityContext().getObject(IdentityContext.TYPE_USER_MODULE);
- (RoleModule)identityServiceController.getIdentityContext().getObject(IdentityContext.TYPE_ROLE_MODULE);
- (MembershipModule)identityServiceController.getIdentityContext().getObject(IdentityContext.TYPE_MEMBERSHIP_MODULE);
- (UserProfileModule)identityServiceController.getIdentityContext().getObject(IdentityContext.TYPE_USER_PROFILE_MODULE);
- </programlisting>
+ <programlisting>
+ (UserModule)identityServiceController.getIdentityContext().getObject(IdentityContext.TYPE_USER_MODULE);
+ (RoleModule)identityServiceController.getIdentityContext().getObject(IdentityContext.TYPE_ROLE_MODULE);
+ (MembershipModule)identityServiceController.getIdentityContext().getObject(IdentityContext.TYPE_MEMBERSHIP_MODULE);
+ (UserProfileModule)identityServiceController.getIdentityContext().getObject(IdentityContext.TYPE_USER_PROFILE_MODULE);
+ </programlisting>
- </sect2>
- <sect2>
- <title>API changes since 2.4</title>
- <para>Because in JBoss Portal 2.4 there were only
- <emphasis role="bold">UserModule</emphasis>
- ,
- <emphasis role="bold">RoleModule</emphasis>
- ,
- <emphasis role="bold">User</emphasis>
- and
- <emphasis role="bold">Role</emphasis>
- interfaces some API usages changed. Here are the most important changes you will need to aply to your
- code while migrating your aplication to 2.6:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- For the <emphasis role="bold">User</emphasis> interface:
- </para>
- <programlisting>
- <![CDATA[
+ </sect2>
+ <sect2>
+ <title>API changes since 2.4</title>
+ <para>Because in JBoss Portal 2.4 there were only
+ <emphasis role="bold">UserModule</emphasis>
+ ,
+ <emphasis role="bold">RoleModule</emphasis>
+ ,
+ <emphasis role="bold">User</emphasis>
+ and
+ <emphasis role="bold">Role</emphasis>
+ interfaces some API usages changed. Here are the most important changes you will need to aply to your
+ code while migrating your aplication to 2.6:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ For the <emphasis role="bold">User</emphasis> interface:
+ </para>
+ <programlisting>
+ <![CDATA[
// Instead of: user.getEnabled()
userProfileModule.getProperty(user, User.INFO_USER_ENABLED);
@@ -372,14 +372,14 @@
// Instead of: user.getLastVisitDate()
userProfileModule.getProperty(user, User.INFO_USER_LAST_LOGIN_DATE);]]>
- </programlisting>
- </listitem>
- <listitem>
- <para>
- The <emphasis role="bold">RoleModule</emphasis> interface:
- </para>
- <programlisting>
- <![CDATA[
+ </programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ The <emphasis role="bold">RoleModule</emphasis> interface:
+ </para>
+ <programlisting>
+ <![CDATA[
// Instead of
// RoleModule.findRoleMembers(String roleName, int offset, int limit, String userNameFilter) throws IdentityException;
membershipModule.findRoleMembers(String roleName, int offset, int limit, String userNameFilter)
@@ -391,24 +391,24 @@
// Instead of
// RoleModule.getRoles(User user) throws IdentityException;
membershipModule.getRoles(User user)]]>
- </programlisting>
- </listitem>
- </itemizedlist>
- </sect2>
- </sect1>
- <sect1>
- <title>How to enable LDAP usage in JBoss Portal</title>
- <para>We'll describe here the simple steps that you'll need to enable LDAP support in JBoss Portal.
- For additional information you need to study more about configuration of identity and specific implementations of identity modules</para>
- <para>There are two ways to achieve this:</para>
- <itemizedlist>
- <listitem>
- <para>In
- <emphasis role="bold">jboss-porta.sar/META-INF/jboss-service.xml</emphasis>
- in section:
- </para>
- <programlisting>
- <![CDATA[
+ </programlisting>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+ </sect1>
+ <sect1>
+ <title>How to enable LDAP usage in JBoss Portal</title>
+ <para>We'll describe here the simple steps that you'll need to enable LDAP support in JBoss Portal.
+ For additional information you need to study more about configuration of identity and specific implementations of identity modules</para>
+ <para>There are two ways to achieve this:</para>
+ <itemizedlist>
+ <listitem>
+ <para>In
+ <emphasis role="bold">jboss-porta.sar/META-INF/jboss-service.xml</emphasis>
+ in section:
+ </para>
+ <programlisting>
+ <![CDATA[
<mbean
code="org.jboss.portal.identity.IdentityServiceControllerImpl"
name="portal:service=Module,type=IdentityServiceController"
@@ -423,29 +423,29 @@
<attribute name="DefaultConfigFile">conf/identity/standardidentity-config.xml</attribute>
</mbean>
]]>
- </programlisting>
- <para>
- change
- <emphasis role="bold">identity-config.xml</emphasis>
- to
- <emphasis role="bold">ldap_identity-config.xml</emphasis>
- </para>
- </listitem>
- <listitem>
- <para>Swap the names or content of files in
- <emphasis role="bold">jboss-porta.sar/conf/identity/identity-config.xml</emphasis>
- and
- <emphasis role="bold">jboss-porta.sar/conf/identity/ldap_identity-config.xml</emphasis>
+ </programlisting>
+ <para>
+ change
+ <emphasis role="bold">identity-config.xml</emphasis>
+ to
+ <emphasis role="bold">ldap_identity-config.xml</emphasis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>Swap the names or content of files in
+ <emphasis role="bold">jboss-porta.sar/conf/identity/identity-config.xml</emphasis>
+ and
+ <emphasis role="bold">jboss-porta.sar/conf/identity/ldap_identity-config.xml</emphasis>
- </para>
- </listitem>
- </itemizedlist>
- <para>
- After doing on of above changes you need to edit configuration file that you choose to
- use (identity-config.xml or ldap_identity-config.xml) and configure LDAP connection options in section:
- </para>
- <programlisting>
- <![CDATA[
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ After doing on of above changes you need to edit configuration file that you choose to
+ use (identity-config.xml or ldap_identity-config.xml) and configure LDAP connection options in section:
+ </para>
+ <programlisting>
+ <![CDATA[
<datasource>
<name>LDAP</name>
<config>
@@ -468,12 +468,12 @@
</config>
</datasource>
]]>
- </programlisting>
- <para>
- You also need to specify options for your LDAP tree (described in configuration documentation) like those:
- </para>
- <programlisting>
- <![CDATA[
+ </programlisting>
+ <para>
+ You also need to specify options for your LDAP tree (described in configuration documentation) like those:
+ </para>
+ <programlisting>
+ <![CDATA[
<option-group>
<group-name>common</group-name>
<option>
@@ -486,21 +486,313 @@
</option>
</option-group>
]]>
- </programlisting>
+ </programlisting>
- </sect1>
- <sect1>
- <title>Identity configuration</title>
- <para>TODO: About the format and architecture of identity configuration files</para>
+ </sect1>
+ <sect1>
+ <title>Identity configuration</title>
+ <para>At the beginning to understand identity configuration you need to understand how it is designed to work in portal.
+ Different identity services like UserModule, RoleModule and etc are just plain java classes that are instantiated and exposed
+ by portal. So *example* UserModule service could be plain java bean object tha will be:
+ <itemizedlist>
+ <listitem><emphasis role="bold">Instantiated</emphasis> using relfection</listitem>
+ <listitem><emphasis role="bold">Initialized/Started</emphasis> by invoking some methods</listitem>
+ <listitem><emphasis role="bold">Registered/Exposed</emphasis> using JNDI and/or mbeans (JBoss Mikrokernel) services, so
+ other citizens of the portal can use it</listitem>
+ <listitem><emphasis role="bold">Managed</emphasis> in the matter of lifecycle - so it'll be stopped and unregistered during
+ portal shutdown</listitem>
+ </itemizedlist>
+ As you see from this standpoint configuration just specifies which java class and how should be used by portal as a service.
+ <note>We use JBoss Microcontainer to manage state of those components so if you are interested in implementation of
+ custom ones - look on the methods that are leveraged by this framework.</note>
+ </para>
+ <para>
+ In JBoss Portal we provide very flexible configuration. It's very easy to rearange and customize services,
+ provide and plug in own implementations, extend current ones or extend identity model with own solutions using
+ provided configuration service.
+ </para>
+ <para>To have the complete picture of the configuration of identity services let's start from it's root
+ component. Whole configuration and setup of identity components is made by
+ <emphasis role="bold">IdentityServiceController</emphasis>. It brings to life and registers all other components
+ like UserModule, RoleModule, MembershipModule and UserProfileModule.
+ <emphasis role="bold">IdentityServiceController</emphasis> is defined in
+ <emphasis>jboss-portal.sar/META-INF/jboss-service.xml</emphasis>
+ </para>
- </sect1>
- <sect1>
- <title>Identity modules implementations</title>
- <para>TODO:</para>
- </sect1>
- <sect1>
- <title>Possible configuration scenarios with LDAP and RDBMS</title>
- <para>TODO:</para>
- </sect1>
+ <programlisting>
+ <![CDATA[
+ <mbean
+ code="org.jboss.portal.identity.IdentityServiceControllerImpl"
+ name="portal:service=Module,type=IdentityServiceController"
+ xmbean-dd=""
+ xmbean-code="org.jboss.portal.jems.as.system.JBossServiceModelMBean">
+ <xmbean/>
+ <depends>portal:service=Hibernate</depends>
+ <!--<depends>jboss.jca:service=DataSourceBinding,name=@portal.datasource.name@</depends>-->
+ <attribute name="JndiName">java:/portal/IdentityServiceController</attribute>
+ <attribute name="RegisterMBeans">true</attribute>
+ <attribute name="ConfigFile">conf/identity/identity-config.xml</attribute>
+ <attribute name="DefaultConfigFile">conf/identity/standardidentity-config.xml</attribute>
+ </mbean>
+ ]]>
+ </programlisting>
+ <para>
+ We can specify few options here:
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis role="bold">RegisterMBeans</emphasis> - defines if IdentityServiceController should
+ register components which are instantiated as mbeans
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">ConfigFile</emphasis> - defines location of main identity services configuration
+ file. It describes and configures all the components like UserModule, RoleModule... that need to be
+ instantiated
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">DefaultConfigFile</emphasis> - defines location of configuration file containing
+ default values. For each component defined in <emphasis role="bold">ConfigFile</emphasis> IdentityServiceController
+ will look into this location to grab set of default options. This simply makes the main configuration file
+ simpler and shorter while still enabling more powerfull customization.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <sect2>
+ <title>Main configuration file architecture (identity-config.xml)</title>
+ <para>
+ The file describing portal identity services contains three sections:
+ </para>
+ <programlisting>
+ <![CDATA[
+ <identity-configuration>
+ <datasources>
+ <!-- Datasources section -->
+ <datasource> ... </datasource>
+ <datasource> ... </datasource>
+ ...
+ </datasources>
+ <modules>
+ <!-- Modules section -->
+ <module> ... </module>
+ <module> ... </module>
+ ...
+ </modules>
+ <options>
+ <!-- Options section -->
+ <option-group> ... </option-group>
+ <option-group> ... </option-group>
+ ...
+ </options>
+ </identity-configuration>
+ ]]>
+ </programlisting>
+ <sect3>
+ <title>Datasources</title>
+ <para>This section defines datasource components. They will be processed and instantiated before components in
+ <emphasis role="bold">Module</emphasis> section, so they will be ready to serve them.</para>
+ <note>This section isn't used whith Database configuration as in JBoss Portal services exposing Hibernate
+ are defined separately. It's used by LDAP configuration and we'll use it as an example</note>
+ <programlisting>
+ <![CDATA[
+ <datasource>
+ <name>LDAP</name>
+ <service-name>portal:service=Module,type=LDAPConnectionContext</service-name>
+ <class>org.jboss.portal.identity.ldap.LDAPConnectionContext</class>
+ <config>
+ <option>
+ <name>host</name>
+ <value>jboss.com</value>
+ </option>
+ <option>
+ <name>port</name>
+ <value>10389</value>
+ </option>
+ <option>
+ <name>adminDN</name>
+ <value>cn=Directory Manager</value>
+ </option>
+ <option>
+ <name>adminPassword</name>
+ <value>xxxxx</value>
+ </option>
+
+ <!-- Other options here.... -->
+
+ </config>
+ </datasource>
+ ]]>
+ </programlisting>
+ <note>If you look into JBoss Portal configuration files you will find that <![CDATA[<service-name/> and <class/>]]>
+ are specified in <emphasis role="bold">DefaultConfigFile</emphasis> and not in <emphasis role="bold">ConfigFile</emphasis>.
+ So this is how it works. Those two will be picked up from default configuration. The same rule takes place
+ for options - additional will be picked up from default configuration. Whats linking configuration in those two files
+ is the <emphasis role="bold"><![CDATA[<name>]]></emphasis> tag.</note>
+ </sect3>
+ <sect3>
+ <title>Modules</title>
+ <para>Modules are core service components like UserModule, RoleModule and etc. </para>
+ <programlisting>
+ <![CDATA[
+ <module>
+ <!--type used to correctly map in IdentityContext registry-->
+ <type>User</type>
+ <implementation>DB</implementation>
+
+ <!--name of service and class for creating mbean-->
+ <service-name>portal:service=Module,type=User</service-name>
+ <class>org.jboss.portal.identity.db.HibernateUserModuleImpl</class>
+
+ <!--set of options that are passed to a class constructor-->
+ <config>
+ <option>
+ <name>sessionFactoryJNDIName</name>
+ <value>java:/portal/IdentitySessionFactory</value>
+ </option>
+ <option>
+ <name>jndiName</name>
+ <value>java:/portal/UserModule</value>
+ </option>
+ </config>
+ </module>
+ ]]>
+ </programlisting>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis role="bold">implementation</emphasis> - defines the scope under which
+ configuration for different implementations of modules <emphasis role="bold">type</emphasis>s are kept.
+ It enables to keep configurations of different implementations of same module types in one configuration file
+ with default options.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">type</emphasis> - must be unique name across all modules defined in the main
+ configuration file. This is important as module will be stored with such name within IdentityContext
+ registry on runtime. Standard names are used (User, Role, Membership, UserProfile). Together with
+ <emphasis role="bold">implementation</emphasis> will create unique pair within file with default configuration values.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">service-name</emphasis> - will be used for registration as an MBean.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">class</emphasis> - java class that will be use to instantiate the module.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">config</emphasis> - contains options related to this module
+ </para>
+ </listitem>
+ </itemizedlist>
+ <note>Here you can easily see the whole idea about having two config files - main one and the one with default values.
+ The above code snippet with User module comes from <emphasis role="bold">standardidentity-config.xml</emphasis>, so the file
+ that defines default configuration values. Because of this in the main configuration file the definition of
+ User module will be as short as:
+ <programlisting>
+ <![CDATA[
+ <module>
+ <!--type used to correctly map in IdentityContext registry-->
+ <type>User</type>
+ <implementation>DB</implementation>
+ <config/>
+ </module>
+ ]]>
+ </programlisting>
+ As you see we specify only type and implementation - all the other values (service-name, class and set of options)
+ will be taken from default configuration. But remember that still you can overwrite any of those values in the
+ main config simply by specifying them.
+ </note>
+
+ </sect3>
+ <sect3>
+ <title>Options</title>
+ <para>This section provides common options that are accessible by identity modules. We put here options
+ that may need to be shared. They are groupped, and can have many values:</para>
+ <programlisting>
+ <![CDATA[
+ <options>
+ <!--Common options section-->
+ <option-group>
+ <group-name>common</group-name>
+ <option>
+ <name>userContainerDN</name>
+ <value>ou=People,dc=example,dc=com</value>
+ </option>
+ <option>
+ <name>uidAttributeID</name>
+ <value>uid</value>
+ </option>
+ <option>
+ <name>passwordAttributeID</name>
+ <value>userPassword</value>
+ </option>
+ <option>
+ <name>roleContainerDN</name>
+ <value>ou=Roles,dc=example,dc=com</value>
+ </option>
+ <option>
+ <name>ridAttributeId</name>
+ <value>cn</value>
+ </option>
+ <option>
+ <name>roleDisplayNameAttributeID</name>
+ <value>cn</value>
+ </option>
+ <option>
+ <name>membershipAttributeID</name>
+ <value>member</value>
+ </option>
+ <option>
+ <name>membershipAttributeIsDN</name>
+ <value>true</value>
+ </option>
+ </option-group>
+ <option-group>
+ <group-name>userCreateAttibutes</group-name>
+ <option>
+ <name>objectClass</name>
+ <value>top</value>
+ <value>uidObject</value>
+ <value>person</value>
+ <value>inetUser</value>
+ </option>
+ <!--Schema requires those to have initial value-->
+ <option>
+ <name>cn</name>
+ <value>none</value>
+ </option>
+ <option>
+ <name>sn</name>
+ <value>none</value>
+ </option>
+ </option-group>
+ ]]>
+ </programlisting>
+ <note>In this section we use the same inheritance mechanism. When option is not set, it's value will be taken
+ from the default config file. But this also means that you need to overwrite some values that
+ are specific for your LDAP architecture. All the options will be described along with module implementations
+ that use them.</note>
+ </sect3>
+ </sect2>
+ </sect1>
+ <sect1>
+ <title>Identity modules implementations</title>
+ <para>TODO:</para>
+ </sect1>
+ <sect1>
+ <title>Possible configuration scenarios with LDAP and RDBMS</title>
+ <para>TODO:</para>
+ </sect1>
+
</chapter>
17 years, 3 months
JBoss Portal SVN: r6133 - docs/tags.
by portal-commits@lists.jboss.org
Author: julien(a)jboss.com
Date: 2007-01-31 10:51:38 -0500 (Wed, 31 Jan 2007)
New Revision: 6133
Added:
docs/tags/JBoss_Portal_2_6_0_ALPHA2/
Log:
tagging alpha 2 docs
Copied: docs/tags/JBoss_Portal_2_6_0_ALPHA2 (from rev 6132, docs/trunk)
17 years, 3 months
JBoss Portal SVN: r6132 - in docs/trunk: referenceGuide/en/modules and 3 other directories.
by portal-commits@lists.jboss.org
Author: roy.russo(a)jboss.com
Date: 2007-01-31 10:36:53 -0500 (Wed, 31 Jan 2007)
New Revision: 6132
Added:
docs/trunk/userGuide/en/images/intro/dashboard_add.gif
Modified:
docs/trunk/referenceGuide/en/master.xml
docs/trunk/referenceGuide/en/modules/migration.xml
docs/trunk/referenceGuide/en/modules/themeandlayouts.xml
docs/trunk/userGuide/en/master.xml
docs/trunk/userGuide/en/modules/intro.xml
Log:
JBPORTAL-1031 - installer update
JBPORTAL-1197 - page cloning
JBPORTAL-1210 - remove layout strat
Modified: docs/trunk/referenceGuide/en/master.xml
===================================================================
--- docs/trunk/referenceGuide/en/master.xml 2007-01-30 23:55:58 UTC (rev 6131)
+++ docs/trunk/referenceGuide/en/master.xml 2007-01-31 15:36:53 UTC (rev 6132)
@@ -26,10 +26,10 @@
]>
<book lang="en">
<bookinfo>
- <title>JBoss Portal 2.6Alpha</title>
+ <title>JBoss Portal 2.6Alpha2</title>
<subtitle>Reference Guide</subtitle>
- <releaseinfo>Release 2.6Alpha "Ninja"</releaseinfo>
- <releaseinfo>October 2006</releaseinfo>
+ <releaseinfo>Release 2.6Alpha2 "Ninja"</releaseinfo>
+ <releaseinfo>February 2007</releaseinfo>
<author>
<firstname>Thomas</firstname>
<surname>Heute</surname>
Modified: docs/trunk/referenceGuide/en/modules/migration.xml
===================================================================
--- docs/trunk/referenceGuide/en/modules/migration.xml 2007-01-30 23:55:58 UTC (rev 6131)
+++ docs/trunk/referenceGuide/en/modules/migration.xml 2007-01-31 15:36:53 UTC (rev 6132)
@@ -11,7 +11,11 @@
<email>boleslaw.dawidowicz at jboss dot com</email>
</author>
</chapterinfo>
- <title>Upgrading 2.2 - 2.4</title>
+ <title>Upgrading 2.4 - 2.6</title>
+ <warning>
+ This section to be updated soon with 2.4 to 2.6 migration instructions, using the Migration Application.
+ </warning>
+<!--
<para>This chapter addresses migration issues from version 2.2 to 2.4 of JBoss Portal.</para>
<sect1 id="migrating_database">
<title>Migrating the Database</title>
@@ -577,5 +581,6 @@
</itemizedlist>
</sect2>
</sect1>
+-->
</chapter>
Modified: docs/trunk/referenceGuide/en/modules/themeandlayouts.xml
===================================================================
--- docs/trunk/referenceGuide/en/modules/themeandlayouts.xml 2007-01-30 23:55:58 UTC (rev 6131)
+++ docs/trunk/referenceGuide/en/modules/themeandlayouts.xml 2007-01-31 15:36:53 UTC (rev 6132)
@@ -72,21 +72,23 @@
themes, we strongly believe that the last approach is superior, and allows for far more
flexibility, and clearer separation of duties between portal developers and web designers.
</para>
- <para>Portal layouts also have the concept of a layout strategy. The layout strategy is a
- pluggable API, and lets the layout developer have a last say about the content to be
- rendered. The strategy is called right after the portal has determined what needs to be
- rendered as part of the current request. So the strategy is invoked right between the point
- where the portal knows what needs to be done, and before the actual work is initiated. The
- strategy gets all the details about what is going to happen, and it can take measures to
- influence those details.
- <itemizedlist>
- <para>Some simple examples of those measures are:</para>
- <listitem>ommit one of the portlets from being rendered</listitem>
- <listitem>change the portlet mode or window state of a portlet before it gets rendered</listitem>
- <listitem>change the layout to be used for this request</listitem>
- <listitem>...and many more</listitem>
- </itemizedlist>
- </para>
+ <!--
+ <para>Portal layouts also have the concept of a layout strategy. The layout strategy is a
+ pluggable API, and lets the layout developer have a last say about the content to be
+ rendered. The strategy is called right after the portal has determined what needs to be
+ rendered as part of the current request. So the strategy is invoked right between the point
+ where the portal knows what needs to be done, and before the actual work is initiated. The
+ strategy gets all the details about what is going to happen, and it can take measures to
+ influence those details.
+ <itemizedlist>
+ <para>Some simple examples of those measures are:</para>
+ <listitem>ommit one of the portlets from being rendered</listitem>
+ <listitem>change the portlet mode or window state of a portlet before it gets rendered</listitem>
+ <listitem>change the layout to be used for this request</listitem>
+ <listitem>...and many more</listitem>
+ </itemizedlist>
+ </para>
+ -->
<para>The last topic to introduce in this overview is the one of portal themes. A theme is a
collection of web design artifacts. It defines a set of css, java script and image files
that together decide about the look and feel of the portal page. The theme can take a wide
@@ -196,21 +198,23 @@
even rebuild the core portal itself.
</para>
</sect2>
+ <!--
+ <sect2>
+ <title>How to connect a Layout to a Layout Strategy</title>
+ <para>As you might have noticed already, a layout definition consists of a name and one or
+ more uri elements. We have already seen the function of the name element. Now let's take
+ a closer look at the uri element. In the example above, the phalanx layout defined one
+ uri element only, the industrial layout defines two. What you can see in the industrial
+ layout is the option of defining different uri's for different states. In this example ,
+ we configured the layout to use a different JSP if the layout state is maximized. If no
+ such separation is made in the layout descriptor, then the portal will always use the
+ same JSP for this layout. Note that the 'state' attribute value works together with the
+ state that was set by the layout strategy. Please refere to the section about the layout
+ strategy for more details.
+ </para>
+ </sect2>
+ -->
<sect2>
- <title>How to connect a Layout to a Layout Strategy</title>
- <para>As you might have noticed already, a layout definition consists of a name and one or
- more uri elements. We have already seen the function of the name element. Now let's take
- a closer look at the uri element. In the example above, the phalanx layout defined one
- uri element only, the industrial layout defines two. What you can see in the industrial
- layout is the option of defining different uri's for different states. In this example ,
- we configured the layout to use a different JSP if the layout state is maximized. If no
- such separation is made in the layout descriptor, then the portal will always use the
- same JSP for this layout. Note that the 'state' attribute value works together with the
- state that was set by the layout strategy. Please refere to the section about the layout
- strategy for more details.
- </para>
- </sect2>
- <sect2>
<title>Layout JSP-tags</title>
<para>The portal comes with a set of JSP tags that allow the layout developer faster
development.
@@ -305,148 +309,152 @@
</para>
</sect2>
</sect1>
- <sect1>
- <title>Layout Strategy</title>
- <sect2>
- <title>What is a Layout Strategy</title>
- <para>The layout strategy is a pluggable API that allows the layout developer to influence
- the content of the page that is about to be rendered. Based on the current request URL,
- the portal determined the portal and page that needs to be rendered. The page contains a
- list of portlets, and those portlets are in a particular navigational state. The
- navigational state consists of the portlet mode and the window state of the portlet.
- This information, togeher with the determined layout, the region and order assignments
- of each portlet, the allowed window states and portlet modes for both, the portal and
- the individual portlets, is passed to the layout strategy before the actual rendering is
- invoked. The layout strategy can check what is about to be rendered, and take action in
- a limited way to influence the content that is about to be rendered.
- </para>
- </sect2>
- <sect2>
- <title>How can I use a Layout Strategy</title>
- <sect3>
- <title>Define a Strategy</title>
- <para>A layout strategy is defined in the strategy descriptor. The descriptor is named
- portal-strategies.xml, and is located in the WEB-INF/layout folder of any web
- application deployed to the server. Here is an example of such a descriptor:
- <programlisting>
- <![CDATA[<portal-strategies>
- <set name="default">
- <strategy content-type="text/html">
- <implementation>org.jboss.portal.theme.impl.strategy.DefaultStrategyImpl</implementation>
- </strategy>
- </set>
- <set name="maximizedRegion">
- <strategy content-type="text/html">
- <implementation>org.jboss.portal.theme.impl.strategy.MaximizingStrategyImpl</implementation>
- </strategy>
- </set>
- </portal-strategies>
- ]]></programlisting>
- Layout strategies are defined as sets. A set consists of one or
- more strategy definitions, separated by content type they are assigned for. The idea
- behind this is to allow the layout developer to apply different strategies based on
- requested content type. Each set has a name that is unique in the application context
- it is deployed in. The strategy can be refered to by this name. As a result of that
- it is considered a named layout strategy in contrast to an anonymous strategy as
- described below.
+ <!--
+<sect1>
+<title>Layout Strategy</title>
+<sect2>
+<title>What is a Layout Strategy</title>
+<para>The layout strategy is a pluggable API that allows the layout developer to influence
+the content of the page that is about to be rendered. Based on the current request URL,
+the portal determined the portal and page that needs to be rendered. The page contains a
+list of portlets, and those portlets are in a particular navigational state. The
+navigational state consists of the portlet mode and the window state of the portlet.
+This information, togeher with the determined layout, the region and order assignments
+of each portlet, the allowed window states and portlet modes for both, the portal and
+the individual portlets, is passed to the layout strategy before the actual rendering is
+invoked. The layout strategy can check what is about to be rendered, and take action in
+a limited way to influence the content that is about to be rendered.
+</para>
+</sect2>
+<sect2>
+<title>How can I use a Layout Strategy</title>
+<sect3>
+<title>Define a Strategy</title>
+<para>A layout strategy is defined in the strategy descriptor. The descriptor is named
+ portal-strategies.xml, and is located in the WEB-INF/layout folder of any web
+ application deployed to the server. Here is an example of such a descriptor:
+ <programlisting>
+ <![CDATA[<portal-strategies>
+ <set name="default">
+ <strategy content-type="text/html">
+ <implementation>org.jboss.portal.theme.impl.strategy.DefaultStrategyImpl</implementation>
+ </strategy>
+ </set>
+ <set name="maximizedRegion">
+ <strategy content-type="text/html">
+ <implementation>org.jboss.portal.theme.impl.strategy.MaximizingStrategyImpl</implementation>
+ </strategy>
+ </set>
+ </portal-strategies>
+ ]]></programlisting>
+ Layout strategies are defined as sets. A set consists of one or
+ more strategy definitions, separated by content type they are assigned for. The idea
+ behind this is to allow the layout developer to apply different strategies based on
+ requested content type. Each set has a name that is unique in the application context
+ it is deployed in. The strategy can be refered to by this name. As a result of that
+ it is considered a named layout strategy in contrast to an anonymous strategy as
+ described below.
+</para>
+</sect3>
+<sect3>
+<title>Specify the Strategy to use</title>
+<para>The strategy that will be used for a portal request is defined as a property of
+ the current layout, the requested portal, or the requested page. If the layout
+ defines a strategy to use it will overwrite all other assignments. If there is no
+ particular strategy defined for the layout, then the page property will overwrite the
+ portal property. If no strategy can be determined, then a last attempt will be made
+ to use the strategy with the name 'default'. If no strategy can be determined at all,
+ the request will proceed normally without invoking any strategy. Here is an example
+ layout descriptor that defines a strategy for the layouts defined:
+ <programlisting>
+ <![CDATA[
+ <layouts>
+ <strategy content-type="text/html">
+ <implementation>com.novell.portal.strategy.MaximizingStrategy</implementation>
+ </strategy>
+
+ <layout>
+ <name>generic</name>
+ <uri>/generic/index.jsp</uri>
+ <uri state="maximized">/generic/maximized.jsp</uri>
+ </layout>
+ </layouts>
+ ]]></programlisting>
+ In this case the strategy is anonymous and directly assigned to
+ the generic layout. The strategy cannot be discovered independently from the generic
+ layout. Here is an example portal descriptor that points to a strategy for the
+ portal, and for a particular page:
+ <programlisting>
+ <![CDATA[
+ <portal>
+ <portal-name>default</portal-name>
+ <properties>
+ <property>
+ <name>layout.strategyId</name>
+ <value>default</value>
+ </property>
+ </properties>
+ <pages>
+ <default-page>theme test</default-page>
+ <page>
+ <page-name>theme test</page-name>
+ <properties>
+ -->
+ <!-- set a difference layout strategy for this page -->
+ <!--
+ <property>
+ <name>layout.strategyId</name>
+ <value>maximizedRegion</value>
+ </property>
+ </properties>
+ <window>
+ <window-name>CatalogPortletWindow</window-name>
+ <instance-ref>CatalogPortletInstance</instance-ref>
+ <region>left</region>
+ <height>0</height>
+ </window>
+ </page>
+ </pages>
+ </portal>
+ ]]></programlisting>
+ As you can see, analogous to how layouts are refered to, the
+ strategy name is the linking element between the portal descriptor and the layout
+ strategy descriptor. The content type is determined at runtime, and serves as a
+ secondary query parameter to get the correct strategy for this content type out of
+ the set that matches the name provided in the portal descriptor.
+ </para>
+ </sect3>
+ </sect2>
+ <sect2>
+ <title>Linking the Strategy and the Layout</title>
+ <para>As mentioned above, the layout descriptor can link a strategy directly to the
+ layout. This will overwrite all other defined strategies for the portal or the page, for
+ any page that uses this layout.
</para>
- </sect3>
- <sect3>
- <title>Specify the Strategy to use</title>
- <para>The strategy that will be used for a portal request is defined as a property of
- the current layout, the requested portal, or the requested page. If the layout
- defines a strategy to use it will overwrite all other assignments. If there is no
- particular strategy defined for the layout, then the page property will overwrite the
- portal property. If no strategy can be determined, then a last attempt will be made
- to use the strategy with the name 'default'. If no strategy can be determined at all,
- the request will proceed normally without invoking any strategy. Here is an example
- layout descriptor that defines a strategy for the layouts defined:
- <programlisting>
- <![CDATA[
+ <para>The layout strategy can set a state to return to the portal as a result of the
+ strategy evaluation. This state will be matched with the state attribute of the uri
+ element of the layout. If there is a match, then the uri that matches this state will be
+ used as the layout for the current request. So, if the strategy sets a state of
+ 'maximized' , the portal will try to use the layout resource that is pointed to for that
+ particular state in the currently selected layout. As you might remember from the
+ previous layout section, a layout can point to another JSP or Servlet based on the state
+ attribute of the uri element, like so:
+ <programlisting><![CDATA[
<layouts>
- <strategy content-type="text/html">
- <implementation>com.novell.portal.strategy.MaximizingStrategy</implementation>
- </strategy>
-
<layout>
- <name>generic</name>
- <uri>/generic/index.jsp</uri>
- <uri state="maximized">/generic/maximized.jsp</uri>
+ <name>industrial</name>
+ <uri>/industrial/index.jsp</uri>
+ <uri state="maximized">/industrial/maximized.jsp</uri>
</layout>
- </layouts>
- ]]></programlisting>
- In this case the strategy is anonymous and directly assigned to
- the generic layout. The strategy cannot be discovered independently from the generic
- layout. Here is an example portal descriptor that points to a strategy for the
- portal, and for a particular page:
- <programlisting>
- <![CDATA[
- <portal>
- <portal-name>default</portal-name>
- <properties>
- <property>
- <name>layout.strategyId</name>
- <value>default</value>
- </property>
- </properties>
- <pages>
- <default-page>theme test</default-page>
- <page>
- <page-name>theme test</page-name>
- <properties>
- <!-- set a difference layout strategy for this page -->
- <property>
- <name>layout.strategyId</name>
- <value>maximizedRegion</value>
- </property>
- </properties>
- <window>
- <window-name>CatalogPortletWindow</window-name>
- <instance-ref>CatalogPortletInstance</instance-ref>
- <region>left</region>
- <height>0</height>
- </window>
- </page>
- </pages>
- </portal>
- ]]></programlisting>
- As you can see, analogous to how layouts are refered to, the
- strategy name is the linking element between the portal descriptor and the layout
- strategy descriptor. The content type is determined at runtime, and serves as a
- secondary query parameter to get the correct strategy for this content type out of
- the set that matches the name provided in the portal descriptor.
+ </layouts>]]></programlisting>
+ In this case all reuquests that don't return a state
+ 'maximized' from the evaluation of the strategy will use the /industrial/index.jsp as
+ the layout. However, if the evaluation of the strategy returns a state of 'maximized'
+ then the request will use /industrial/maximized.jsp as the layout.
</para>
- </sect3>
- </sect2>
- <sect2>
- <title>Linking the Strategy and the Layout</title>
- <para>As mentioned above, the layout descriptor can link a strategy directly to the
- layout. This will overwrite all other defined strategies for the portal or the page, for
- any page that uses this layout.
- </para>
- <para>The layout strategy can set a state to return to the portal as a result of the
- strategy evaluation. This state will be matched with the state attribute of the uri
- element of the layout. If there is a match, then the uri that matches this state will be
- used as the layout for the current request. So, if the strategy sets a state of
- 'maximized' , the portal will try to use the layout resource that is pointed to for that
- particular state in the currently selected layout. As you might remember from the
- previous layout section, a layout can point to another JSP or Servlet based on the state
- attribute of the uri element, like so:
- <programlisting><![CDATA[
- <layouts>
- <layout>
- <name>industrial</name>
- <uri>/industrial/index.jsp</uri>
- <uri state="maximized">/industrial/maximized.jsp</uri>
- </layout>
- </layouts>]]></programlisting>
- In this case all reuquests that don't return a state
- 'maximized' from the evaluation of the strategy will use the /industrial/index.jsp as
- the layout. However, if the evaluation of the strategy returns a state of 'maximized'
- then the request will use /industrial/maximized.jsp as the layout.
- </para>
- </sect2>
- </sect1>
+ </sect2>
+ </sect1>
+ -->
<sect1>
<title>RenderSets</title>
<sect2>
Added: docs/trunk/userGuide/en/images/intro/dashboard_add.gif
===================================================================
(Binary files differ)
Property changes on: docs/trunk/userGuide/en/images/intro/dashboard_add.gif
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Modified: docs/trunk/userGuide/en/master.xml
===================================================================
--- docs/trunk/userGuide/en/master.xml 2007-01-30 23:55:58 UTC (rev 6131)
+++ docs/trunk/userGuide/en/master.xml 2007-01-31 15:36:53 UTC (rev 6132)
@@ -13,10 +13,10 @@
]>
<book lang="en">
<bookinfo>
- <title>JBoss Portal 2.6Alpha</title>
+ <title>JBoss Portal 2.6Alpha2</title>
<subtitle>User Guide</subtitle>
- <releaseinfo>Release 2.6Alpha "Ninja"</releaseinfo>
- <releaseinfo>October 2006</releaseinfo>
+ <releaseinfo>Release 2.6Alpha2 "Ninja"</releaseinfo>
+ <releaseinfo>February 2007</releaseinfo>
<author>
<firstname>Roy</firstname>
<surname>Russo</surname>
Modified: docs/trunk/userGuide/en/modules/intro.xml
===================================================================
--- docs/trunk/userGuide/en/modules/intro.xml 2007-01-30 23:55:58 UTC (rev 6131)
+++ docs/trunk/userGuide/en/modules/intro.xml 2007-01-31 15:36:53 UTC (rev 6132)
@@ -544,6 +544,17 @@
While navigating any of the dashboard pages, a user will be able to drag and drop portlet windows to any
location, if the administrator allows this functionality. Changes made in this fashion will be persisted.
</para>
+ <para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/intro/dashboard_add.gif" format="gif" align="center"
+ valign="middle"/>
+ </imageobject>
+ </mediaobject>
+ You are also able to add(clone) shared pages to your personal dashboard, by selecting the
+ <emphasis>Add to Dashboard</emphasis>
+ link. This will clone the page and add it to your personal dashboard as a page with the same name.
+ </para>
<sect2 id="dashboard_configure">
<title>Configuring your personal dashboard</title>
<para>
17 years, 3 months
JBoss Portal SVN: r6131 - docs/trunk/referenceGuide/en/modules.
by portal-commits@lists.jboss.org
Author: julien(a)jboss.com
Date: 2007-01-30 18:55:58 -0500 (Tue, 30 Jan 2007)
New Revision: 6131
Modified:
docs/trunk/referenceGuide/en/modules/identity.xml
Log:
updated the identity doc wording
Modified: docs/trunk/referenceGuide/en/modules/identity.xml
===================================================================
--- docs/trunk/referenceGuide/en/modules/identity.xml 2007-01-30 23:25:48 UTC (rev 6130)
+++ docs/trunk/referenceGuide/en/modules/identity.xml 2007-01-30 23:55:58 UTC (rev 6131)
@@ -10,19 +10,17 @@
<para>This chapter addresses identity management in JBoss Portal 2.6</para>
<sect1 id="management_api">
<title>Identity management API</title>
- <para>In JBoss Portal currently there are 4 identity modules and 2 identity reletad objects. The goal about
- having such wide API is to
- enable flexible implementations related to different underlaying technologies like RDBS or LDAP. With such
- data storage mechanisms things like
- User/Role relationship are defined in slightly different way. Another thing is User Profile where
- information about user can be grabbed from database
- column or LDAP entry or even mixed.
+ <para>Since JBoss Portal 2.6 there are 4 identity services and 2 identity related interfaces. The goal of
+ having such a fine grained API is to enable flexible implementations based on different
+ identity storage like relational databases or LDAP servers. The Membership service takes care of managing the relationship
+ between user objects and role objects. The User Profile service is responsible for managing the profile of a user,
+ it has database and LDAP implementations as well as a mode that combines data from both.
</para>
<itemizedlist>
<listitem>
<para>
- <emphasis role="bold">User</emphasis>
- interface which exposes such operations on User object:
+ The <emphasis role="bold">org.jboss.portal.identity.User</emphasis>
+ interface represents a user and exposes the following operations:
</para>
<programlisting>
<![CDATA[
@@ -40,28 +38,30 @@
]]>
</programlisting>
<warning>
- Important Note!!! Proper usage of getId() method is:
+ Important Note! The proper usage of getId() method is:
<programlisting>
<![CDATA[
- //Always use it like this:
- user.getId().toString()
+ // Always use it like this:
+ user.getId().toString();
- //NEVER use it like this:
- (Long)user.getId()
- (String)user.getId()
+ // Do not use it like this:
+
+ // We would get a Long object if we are using the database implementation
+ (Long)user.getId();
+
+ // We would get a String with an LDAP server
+ (String)user.getId();
]]>
</programlisting>
- This is because of that ID depends on User implementation. It'll probably be String in LDAP and Long
- in Hibernate but it can be anything else...
-
+ This is because the ID value depends on the User implementation. It'll probably be String object with the LDAP
+ implementation and a Long object with the database implementation but it could be something else
+ if one has chosen to make its own implementation.
</warning>
</listitem>
<listitem>
<para>
- <emphasis role="bold">Role</emphasis>
- interface which exposes such operations on
- <emphasis role="bold">User</emphasis>
- object:
+ The <emphasis role="bold">org.jboss.portal.identity.Role</emphasis> interface represents a Role
+ and exposes the following operations:
</para>
<programlisting>
<![CDATA[
@@ -81,8 +81,8 @@
</listitem>
<listitem>
<para>
- <emphasis role="bold">UserModule</emphasis>
- interface which exposes operations for users management
+ The <emphasis role="bold">org.jboss.portal.identity.UserModule</emphasis>
+ interface exposes operations for users management:
</para>
<programlisting>
<![CDATA[
@@ -114,8 +114,8 @@
</listitem>
<listitem>
<para>
- <emphasis role="bold">RoleModule</emphasis>
- interface which exposes operations for roles management
+ The <emphasis role="bold">org.jboss.portal.identity.RoleModule</emphasis>
+ interface exposes operations for roles management:
</para>
<programlisting>
<![CDATA[
@@ -169,14 +169,12 @@
</listitem>
<listitem>
<para>
- <emphasis role="bold">MembershipModule</emphasis>
- interface which exposes operations for obtaining or defining relationship beetween users and roles.
- The role of this module is to
- decouple relationship information from user and roles. Whith different implementations definition of
- such relationship can be specified on different sides.
- With Relational DB it's quite simple, but in LDAP there are several ways to store such information.
- Role of this module is to bring flexibility
- in defining contract beetween user and role.
+ The <emphasis role="bold">MembershipModule</emphasis>
+ interface exposes operations for obtaining or managing relationships beetween users and roles.
+ The role of this service is to decouple relationship information from user and roles.
+ Indeed while user role relationship is pretty straightforward with a relational database (using
+ a many to many relationship with an intermediary table), with an LDAP server there a different
+ ways to define relationships between users and roles.
</para>
<programlisting>
<![CDATA[
@@ -198,8 +196,8 @@
</listitem>
<listitem>
<para>
- <emphasis role="bold">UserProfileModule</emphasis>
- interface which exposes operations to access informations stored in User profile.
+ The <emphasis role="bold">UserProfileModule</emphasis>
+ interface exposes operations to access and manage informations stored in User profile:
</para>
<programlisting>
<![CDATA[
@@ -213,17 +211,17 @@
]]>
</programlisting>
<warning>
- UserProfileModule?.getProperty() method returns Object.
+ UserProfileModule.getProperty() method returns an Object.
In most cases with DB backend it will always be String object. But normally you should check what
object will be retreived using getProfileInfo() method.
</warning>
</listitem>
<listitem>
<para>
- <emphasis role="bold">ProfileInfo</emphasis>
- interface which can be obtained using
+ The <emphasis role="bold">ProfileInfo</emphasis>
+ interface can be obtained using the
<emphasis role="bold">UserProfileModule</emphasis>
- and exposes information about User profile properties that are accessible:
+ and exposes meta information of a profile:
</para>
<programlisting>
<![CDATA[
@@ -276,7 +274,7 @@
</itemizedlist>
<sect2>
- <title>Way to access identity modules</title>
+ <title>Ways to access identity modules</title>
<para>
The best way to access identity modules is by using JNDI:
</para>
@@ -295,18 +293,18 @@
</programlisting>
<para>
- Another way to do this is, if you are fimiliar with JBoss Mikrokernel architecture is by obtaining
- <emphasis role="bold">IdentityServiceController</emphasis>
- mbean. You may want to inject it into your mbean like this:
+ Another way to do this is, if you are fimiliar with JBoss Mikrokernel architecture is to
+ get the <emphasis role="bold">IdentityServiceController</emphasis>
+ mbean. You may want to inject it into your services like this:
</para>
<programlisting>
<![CDATA[<depends optional-attribute-name="IdentityServiceController" proxy-type="attribute">portal:service=Module,type=IdentityServiceController</depends>]]>
</programlisting>
<para>
- or simply obtain in your code using
- <emphasis role="bold">portal:service=Module,type=IdentityServiceController</emphasis>
- name. Please refer to JBoss Application Server documentation if you want to learn more
- about MBeans. Once you obtained the object you can use it:
+ or simply obtain in your code by doing a lookup using
+ the <emphasis role="bold">portal:service=Module,type=IdentityServiceController</emphasis>
+ name. Please refer to the JBoss Application Server documentation if you want to learn more
+ about service MBeans. Once you obtained the object you can use it:
</para>
<programlisting>
@@ -328,90 +326,81 @@
and
<emphasis role="bold">Role</emphasis>
interfaces some API usages changed. Here are the most important changes you will need to aply to your
- code
- while migrating your aplication to 2.6:
+ code while migrating your aplication to 2.6:
</para>
<itemizedlist>
<listitem>
<para>
- <emphasis role="bold">User</emphasis>
- interface
+ For the <emphasis role="bold">User</emphasis> interface:
</para>
<programlisting>
<![CDATA[
- //Instead of: user.getEnabled()
+ // Instead of: user.getEnabled()
userProfileModule.getProperty(user, User.INFO_USER_ENABLED);
- //Instead of: user.setEnabled(value)
+ // Instead of: user.setEnabled(value)
userProfileModule.setProperty(user, User.INFO_USER_ENABLED, value);
- In the similar way you should change rest of methods that are missing in User interface in 2.6 by the call to the UserProfileModule?:
+ // In a similar way you should change rest of methods that are missing in User interface in 2.6 by the call to the UserProfileModule
- //Instead of: user.getProperties()
+ // Instead of: user.getProperties()
userProfileModule.getProperties(user);
- //Instead of: user.getGivenName()
+ // Instead of: user.getGivenName()
userProfileModule.getProperty(user, User.INFO_USER_NAME_GIVEN);
- //Instead of: user.getFamilyName()
+ // Instead of: user.getFamilyName()
userProfileModule.getProperty(user, User.INFO_USER_NAME_FAMILY);
- //Instead of: user.getRealEmail()
+ // Instead of: user.getRealEmail()
userProfileModule.getProperty(user, User.INFO_USER_EMAIL_REAL);
- //Instead of: user.getFakeEmail()
+ // Instead of: user.getFakeEmail()
userProfileModule.getProperty(user, User.INFO_USER_EMAIL_FAKE);
- //Instead of: user.getRegistrationDate()
+ // Instead of: user.getRegistrationDate()
userProfileModule.getProperty(user, User.INFO_USER_REGISTRATION_DATE);
- //Instead of: user.getViewRealEmail()
+ // Instead of: user.getViewRealEmail()
userProfileModule.getProperty(user, User.INFO_USER_VIEW_EMAIL_VIEW_REAL);
- //Instead of: user.getPreferredLocale()
+ // Instead of: user.getPreferredLocale()
userProfileModule.getProperty(user, User.INFO_USER_LOCALE);
- //Instead of: user.getSignature()
+ // Instead of: user.getSignature()
userProfileModule.getProperty(user, User.INFO_USER_SIGNATURE);
- //Instead of: user.getLastVisitDate()
- userProfileModule.getProperty(user, User.INFO_USER_LAST_LOGIN_DATE);
-
- ]]>
+ // Instead of: user.getLastVisitDate()
+ userProfileModule.getProperty(user, User.INFO_USER_LAST_LOGIN_DATE);]]>
</programlisting>
</listitem>
<listitem>
<para>
- <emphasis role="bold">RoleModule</emphasis>
- interface
+ The <emphasis role="bold">RoleModule</emphasis> interface:
</para>
<programlisting>
<![CDATA[
- //Instead of
- //RoleModule.findRoleMembers(String roleName, int offset, int limit, String userNameFilter) throws IdentityException;
+ // Instead of
+ // RoleModule.findRoleMembers(String roleName, int offset, int limit, String userNameFilter) throws IdentityException;
membershipModule.findRoleMembers(String roleName, int offset, int limit, String userNameFilter)
- //Instead of
- //RoleModule.setRoles(User user, Set roles) throws IdentityException;
+ // Instead of
+ // RoleModule.setRoles(User user, Set roles) throws IdentityException;
membershipModule.assignRoles(User user, Set roles)
- //Instead of
- //RoleModule.getRoles(User user) throws IdentityException;
- membershipModule.getRoles(User user)
-
- ]]>
+ // Instead of
+ // RoleModule.getRoles(User user) throws IdentityException;
+ membershipModule.getRoles(User user)]]>
</programlisting>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1>
- <title>How to enable LDAP in JBoss Portal</title>
- <para>Here are just few simple steps you'll need to enable LDAP support in JBoss Portal. For additional
- information you need to study more about
- configuration of identity and specific implementations of identity modules
- </para>
- <para>There are two ways to achive this goal:</para>
+ <title>How to enable LDAP usage in JBoss Portal</title>
+ <para>We'll describe here the simple steps that you'll need to enable LDAP support in JBoss Portal.
+ For additional information you need to study more about configuration of identity and specific implementations of identity modules</para>
+ <para>There are two ways to achieve this:</para>
<itemizedlist>
<listitem>
<para>In
17 years, 3 months
JBoss Portal SVN: r6130 - docs/trunk/referenceGuide/en/modules.
by portal-commits@lists.jboss.org
Author: bdaw
Date: 2007-01-30 18:25:48 -0500 (Tue, 30 Jan 2007)
New Revision: 6130
Modified:
docs/trunk/referenceGuide/en/modules/identity.xml
Log:
typo fix
Modified: docs/trunk/referenceGuide/en/modules/identity.xml
===================================================================
--- docs/trunk/referenceGuide/en/modules/identity.xml 2007-01-30 23:09:26 UTC (rev 6129)
+++ docs/trunk/referenceGuide/en/modules/identity.xml 2007-01-30 23:25:48 UTC (rev 6130)
@@ -407,12 +407,15 @@
</sect1>
<sect1>
<title>How to enable LDAP in JBoss Portal</title>
- <para>Here are just few simple steps you'll need to enable LDAP support in JBoss Portal. For additional information you need to study more about
- configuration of identity and specific implementations of identity modules</para>
+ <para>Here are just few simple steps you'll need to enable LDAP support in JBoss Portal. For additional
+ information you need to study more about
+ configuration of identity and specific implementations of identity modules
+ </para>
<para>There are two ways to achive this goal:</para>
<itemizedlist>
<listitem>
- <para>In <emphasis role="bold">jboss-porta.sar/META-INF/jboss-service.xml</emphasis>
+ <para>In
+ <emphasis role="bold">jboss-porta.sar/META-INF/jboss-service.xml</emphasis>
in section:
</para>
<programlisting>
@@ -433,8 +436,10 @@
]]>
</programlisting>
<para>
- change <emphasis role="bold">identity-config.xml</emphasis> to
- <emphasis role="bold">ldap_identity-config.xml</emphasis>
+ change
+ <emphasis role="bold">identity-config.xml</emphasis>
+ to
+ <emphasis role="bold">ldap_identity-config.xml</emphasis>
</para>
</listitem>
<listitem>
@@ -442,15 +447,16 @@
<emphasis role="bold">jboss-porta.sar/conf/identity/identity-config.xml</emphasis>
and
<emphasis role="bold">jboss-porta.sar/conf/identity/ldap_identity-config.xml</emphasis>
-
- </para>
+
+ </para>
</listitem>
- <para>
- After doing on of above changes you need to edit configuration file that you choose to
- use (identity-config.xml or ldap_identity-config.xml) and configure LDAP connection options in section:
- </para>
- <programlisting>
- <![CDATA[
+ </itemizedlist>
+ <para>
+ After doing on of above changes you need to edit configuration file that you choose to
+ use (identity-config.xml or ldap_identity-config.xml) and configure LDAP connection options in section:
+ </para>
+ <programlisting>
+ <![CDATA[
<datasource>
<name>LDAP</name>
<config>
@@ -473,12 +479,12 @@
</config>
</datasource>
]]>
- </programlisting>
- <para>
- You also need to specify options for your LDAP tree (described in configuration documentation) like those:
- </para>
- <programlisting>
- <![CDATA[
+ </programlisting>
+ <para>
+ You also need to specify options for your LDAP tree (described in configuration documentation) like those:
+ </para>
+ <programlisting>
+ <![CDATA[
<option-group>
<group-name>common</group-name>
<option>
@@ -491,10 +497,9 @@
</option>
</option-group>
]]>
- </programlisting>
+ </programlisting>
- </itemizedlist>
</sect1>
<sect1>
<title>Identity configuration</title>
17 years, 3 months
JBoss Portal SVN: r6129 - docs/trunk/referenceGuide/en/modules.
by portal-commits@lists.jboss.org
Author: bdaw
Date: 2007-01-30 18:09:26 -0500 (Tue, 30 Jan 2007)
New Revision: 6129
Modified:
docs/trunk/referenceGuide/en/modules/identity.xml
docs/trunk/referenceGuide/en/modules/sso.xml
Log:
few more things in identity and sso toc
Modified: docs/trunk/referenceGuide/en/modules/identity.xml
===================================================================
--- docs/trunk/referenceGuide/en/modules/identity.xml 2007-01-30 22:33:11 UTC (rev 6128)
+++ docs/trunk/referenceGuide/en/modules/identity.xml 2007-01-30 23:09:26 UTC (rev 6129)
@@ -405,6 +405,108 @@
</itemizedlist>
</sect2>
</sect1>
-
+ <sect1>
+ <title>How to enable LDAP in JBoss Portal</title>
+ <para>Here are just few simple steps you'll need to enable LDAP support in JBoss Portal. For additional information you need to study more about
+ configuration of identity and specific implementations of identity modules</para>
+ <para>There are two ways to achive this goal:</para>
+ <itemizedlist>
+ <listitem>
+ <para>In <emphasis role="bold">jboss-porta.sar/META-INF/jboss-service.xml</emphasis>
+ in section:
+ </para>
+ <programlisting>
+ <![CDATA[
+ <mbean
+ code="org.jboss.portal.identity.IdentityServiceControllerImpl"
+ name="portal:service=Module,type=IdentityServiceController"
+ xmbean-dd=""
+ xmbean-code="org.jboss.portal.jems.as.system.JBossServiceModelMBean">
+ <xmbean/>
+ <depends>portal:service=Hibernate</depends>
+ <!--<depends>jboss.jca:service=DataSourceBinding,name=@portal.datasource.name@</depends>-->
+ <attribute name="JndiName">java:/portal/IdentityServiceController</attribute>
+ <attribute name="RegisterMBeans">true</attribute>
+ <attribute name="ConfigFile">conf/identity/identity-config.xml</attribute>
+ <attribute name="DefaultConfigFile">conf/identity/standardidentity-config.xml</attribute>
+ </mbean>
+ ]]>
+ </programlisting>
+ <para>
+ change <emphasis role="bold">identity-config.xml</emphasis> to
+ <emphasis role="bold">ldap_identity-config.xml</emphasis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>Swap the names or content of files in
+ <emphasis role="bold">jboss-porta.sar/conf/identity/identity-config.xml</emphasis>
+ and
+ <emphasis role="bold">jboss-porta.sar/conf/identity/ldap_identity-config.xml</emphasis>
+
+ </para>
+ </listitem>
+ <para>
+ After doing on of above changes you need to edit configuration file that you choose to
+ use (identity-config.xml or ldap_identity-config.xml) and configure LDAP connection options in section:
+ </para>
+ <programlisting>
+ <![CDATA[
+ <datasource>
+ <name>LDAP</name>
+ <config>
+ <option>
+ <name>host</name>
+ <value>jboss.com</value>
+ </option>
+ <option>
+ <name>port</name>
+ <value>10389</value>
+ </option>
+ <option>
+ <name>adminDN</name>
+ <value>cn=Directory Manager</value>
+ </option>
+ <option>
+ <name>adminPassword</name>
+ <value>qpq123qpq</value>
+ </option>
+ </config>
+ </datasource>
+ ]]>
+ </programlisting>
+ <para>
+ You also need to specify options for your LDAP tree (described in configuration documentation) like those:
+ </para>
+ <programlisting>
+ <![CDATA[
+ <option-group>
+ <group-name>common</group-name>
+ <option>
+ <name>userContainerDN</name>
+ <value>ou=People,dc=portal26,dc=jboss,dc=com</value>
+ </option>
+ <option>
+ <name>roleContainerDN</name>
+ <value>ou=Roles,dc=portal26,dc=jboss,dc=com</value>
+ </option>
+ </option-group>
+ ]]>
+ </programlisting>
+
+ </itemizedlist>
+ </sect1>
+ <sect1>
+ <title>Identity configuration</title>
+ <para>TODO: About the format and architecture of identity configuration files</para>
+
+ </sect1>
+ <sect1>
+ <title>Identity modules implementations</title>
+ <para>TODO:</para>
+ </sect1>
+ <sect1>
+ <title>Possible configuration scenarios with LDAP and RDBMS</title>
+ <para>TODO:</para>
+ </sect1>
</chapter>
Modified: docs/trunk/referenceGuide/en/modules/sso.xml
===================================================================
--- docs/trunk/referenceGuide/en/modules/sso.xml 2007-01-30 22:33:11 UTC (rev 6128)
+++ docs/trunk/referenceGuide/en/modules/sso.xml 2007-01-30 23:09:26 UTC (rev 6129)
@@ -6,8 +6,19 @@
<email>boleslaw.dawidowicz at jboss dot com</email>
</author>
</chapterinfo>
- <title>Authentication</title>
+ <title>Single Sign ON</title>
<para>This chapter describes how to setup SSO in JBoss Portal</para>
-
+ <sect1>
+ <title>Overview of SSO in portal</title>
+ <para>TODO:</para>
+ </sect1>
+ <sect1>
+ <title>Using Tomcat Valve</title>
+ <para>TODO:</para>
+ </sect1>
+ <sect1>
+ <title>Using external authentication providers</title>
+ <para>TODO:</para>
+ </sect1>
</chapter>
17 years, 3 months
JBoss Portal SVN: r6128 - docs/trunk/referenceGuide/en/modules.
by portal-commits@lists.jboss.org
Author: bdaw
Date: 2007-01-30 17:33:11 -0500 (Tue, 30 Jan 2007)
New Revision: 6128
Added:
docs/trunk/referenceGuide/en/modules/authentication.xml
docs/trunk/referenceGuide/en/modules/identity.xml
docs/trunk/referenceGuide/en/modules/sso.xml
Log:
some initial work on identity, and placeholders for authentication and sso chapters
Added: docs/trunk/referenceGuide/en/modules/authentication.xml
===================================================================
--- docs/trunk/referenceGuide/en/modules/authentication.xml (rev 0)
+++ docs/trunk/referenceGuide/en/modules/authentication.xml 2007-01-30 22:33:11 UTC (rev 6128)
@@ -0,0 +1,12 @@
+<chapter id="authentication">
+ <chapterinfo>
+ <author>
+ <firstname>Boleslaw</firstname>
+ <surname>Dawidowicz</surname>
+ <email>boleslaw.dawidowicz at jboss dot com</email>
+ </author>
+ </chapterinfo>
+ <title>Authentication</title>
+ <para>This chapter describes authentication mechanisms in JBoss Portal</para>
+
+</chapter>
Added: docs/trunk/referenceGuide/en/modules/identity.xml
===================================================================
--- docs/trunk/referenceGuide/en/modules/identity.xml (rev 0)
+++ docs/trunk/referenceGuide/en/modules/identity.xml 2007-01-30 22:33:11 UTC (rev 6128)
@@ -0,0 +1,410 @@
+<chapter id="identity">
+ <chapterinfo>
+ <author>
+ <firstname>Boleslaw</firstname>
+ <surname>Dawidowicz</surname>
+ <email>boleslaw.dawidowicz at jboss dot com</email>
+ </author>
+ </chapterinfo>
+ <title>JBoss Portal Identity management</title>
+ <para>This chapter addresses identity management in JBoss Portal 2.6</para>
+ <sect1 id="management_api">
+ <title>Identity management API</title>
+ <para>In JBoss Portal currently there are 4 identity modules and 2 identity reletad objects. The goal about
+ having such wide API is to
+ enable flexible implementations related to different underlaying technologies like RDBS or LDAP. With such
+ data storage mechanisms things like
+ User/Role relationship are defined in slightly different way. Another thing is User Profile where
+ information about user can be grabbed from database
+ column or LDAP entry or even mixed.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis role="bold">User</emphasis>
+ interface which exposes such operations on User object:
+ </para>
+ <programlisting>
+ <![CDATA[
+ /** The user identifier. */
+ public Object getId();
+
+ /** The user name. */
+ public String getUserName();
+
+ /** Set the password using proper encoding. */
+ public void updatePassword(String password);
+
+ /** Return true if the password is valid. */
+ public boolean validatePassword(String password);
+ ]]>
+ </programlisting>
+ <warning>
+ Important Note!!! Proper usage of getId() method is:
+ <programlisting>
+ <![CDATA[
+ //Always use it like this:
+ user.getId().toString()
+
+ //NEVER use it like this:
+ (Long)user.getId()
+ (String)user.getId()
+ ]]>
+ </programlisting>
+ This is because of that ID depends on User implementation. It'll probably be String in LDAP and Long
+ in Hibernate but it can be anything else...
+
+ </warning>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">Role</emphasis>
+ interface which exposes such operations on
+ <emphasis role="bold">User</emphasis>
+ object:
+ </para>
+ <programlisting>
+ <![CDATA[
+ /** The role identifier. */
+ public Object getId();
+
+ /** The role name used in security rules. This name can not be modified */
+ public String getName();
+
+ /** The role display name used on screens. This name can be modified */
+ public String getDisplayName();
+
+ /** */
+ public void setDisplayName(String name);
+ ]]>
+ </programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">UserModule</emphasis>
+ interface which exposes operations for users management
+ </para>
+ <programlisting>
+ <![CDATA[
+ /**Retrieve a user by its name.*/
+ User findUserByUserName(String userName) throws IdentityException, IllegalArgumentException, NoSuchUserException;
+
+ /**Retrieve a user by its id.*/
+ User findUserById(Object id) throws IdentityException, IllegalArgumentException, NoSuchUserException;
+
+ /**Retrieve a user by its id.*/
+ User findUserById(String id) throws IdentityException, IllegalArgumentException, NoSuchUserException;
+
+ /** Creates a new user with the specified name.*/
+ User createUser(String userName, String password) throws IdentityException, IllegalArgumentException;
+
+ /** Remove a user.*/
+ void removeUser(Object id) throws IdentityException, IllegalArgumentException;
+
+ /** Get a range of users.*/
+ Set findUsers(int offset, int limit) throws IdentityException, IllegalArgumentException;
+
+ /** Get a range of users.*/
+ Set findUsersFilteredByUserName(String filter, int offset, int limit) throws IdentityException, IllegalArgumentException;
+
+ /**Returns the number of users.*/
+ int getUserCount() throws IdentityException, IllegalArgumentException;
+ ]]>
+ </programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">RoleModule</emphasis>
+ interface which exposes operations for roles management
+ </para>
+ <programlisting>
+ <![CDATA[
+ /** Retrieves a role by its name*/
+ Role findRoleByName(String name) throws IdentityException, IllegalArgumentException;
+
+ /**Retrieve a collection of role from the role names.*/
+ Set findRolesByNames(String[] names) throws IdentityException, IllegalArgumentException;
+
+ /** Retrieves a role by its id.*/
+ Role findRoleById(Object id) throws IdentityException, IllegalArgumentException;
+
+ /** Retrieves a role by its id.*/
+ Role findRoleById(String id) throws IdentityException, IllegalArgumentException;
+
+ /** Create a new role with the specified name.*/
+ Role createRole(String name, String displayName) throws IdentityException, IllegalArgumentException;
+
+ /** Remove a role.*/
+ void removeRole(Object id) throws IdentityException, IllegalArgumentException;
+
+ /** Returns the number of roles. */
+ int getRolesCount() throws IdentityException;
+
+ /** Get all the roles */
+ Set findRoles() throws IdentityException;/** Retrieves a role by its name*/
+ Role findRoleByName(String name) throws IdentityException, IllegalArgumentException;
+
+ /**Retrieve a collection of role from the role names.*/
+ Set findRolesByNames(String[] names) throws IdentityException, IllegalArgumentException;
+
+ /** Retrieves a role by its id.*/
+ Role findRoleById(Object id) throws IdentityException, IllegalArgumentException;
+
+ /** Retrieves a role by its id.*/
+ Role findRoleById(String id) throws IdentityException, IllegalArgumentException;
+
+ /** Create a new role with the specified name.*/
+ Role createRole(String name, String displayName) throws IdentityException, IllegalArgumentException;
+
+ /** Remove a role.*/
+ void removeRole(Object id) throws IdentityException, IllegalArgumentException;
+
+ /** Returns the number of roles. */
+ int getRolesCount() throws IdentityException;
+
+ /** Get all the roles */
+ Set findRoles() throws IdentityException;
+ ]]>
+ </programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">MembershipModule</emphasis>
+ interface which exposes operations for obtaining or defining relationship beetween users and roles.
+ The role of this module is to
+ decouple relationship information from user and roles. Whith different implementations definition of
+ such relationship can be specified on different sides.
+ With Relational DB it's quite simple, but in LDAP there are several ways to store such information.
+ Role of this module is to bring flexibility
+ in defining contract beetween user and role.
+ </para>
+ <programlisting>
+ <![CDATA[
+ /** Return the set of role objects that a given user has.*/
+ Set getRoles(User user) throws IdentityException, IllegalArgumentException;
+
+ Set getUsers(Role role) throws IdentityException, IllegalArgumentException;
+
+ /** Creates a relationship beetween a role and set of users. Other roles that have assotiontions with those users remain unaffected.*/
+ void assignUsers(Role role, Set users) throws IdentityException, IllegalArgumentException;
+
+ /** Creates a relationship beetween a user and set of roles. This operation will erase any other assotientions beetween the user and roles not specified in the provided set.*/
+ void assignRoles(User user, Set roles) throws IdentityException, IllegalArgumentException;
+
+ /** Returns role members based on rolename - depreciated method ethod here only for compatibility with old RoleModule interface */
+ Set findRoleMembers(String roleName, int offset, int limit, String userNameFilter) throws IdentityException, IllegalArgumentException;
+ ]]>
+ </programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">UserProfileModule</emphasis>
+ interface which exposes operations to access informations stored in User profile.
+ </para>
+ <programlisting>
+ <![CDATA[
+ public Object getProperty(User user, String propertyName) throws IdentityException, IllegalArgumentException;
+
+ public void setProperty(User user, String name, Object property) throws IdentityException, IllegalArgumentException;
+
+ public Map getProperties(User user) throws IdentityException, IllegalArgumentException;
+
+ public ProfileInfo getProfileInfo() throws IdentityException;
+ ]]>
+ </programlisting>
+ <warning>
+ UserProfileModule?.getProperty() method returns Object.
+ In most cases with DB backend it will always be String object. But normally you should check what
+ object will be retreived using getProfileInfo() method.
+ </warning>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">ProfileInfo</emphasis>
+ interface which can be obtained using
+ <emphasis role="bold">UserProfileModule</emphasis>
+ and exposes information about User profile properties that are accessible:
+ </para>
+ <programlisting>
+ <![CDATA[
+ /** Returns a Map o PropertyInfo objects describing profile properties */
+ public Map getPropertiesInfo();
+
+ public PropertyInfo getPropertyInfo(String name);
+ ]]>
+ </programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">PropertyInfo</emphasis>
+ interface expose methods to obtain information about accessible property in User profile
+ </para>
+ <programlisting>
+ <![CDATA[
+ public static final String ACCESS_MODE_READ_ONLY = "read-only";
+ public static final String ACCESS_MODE_READ_WRITE = "read-write";
+ public static final String USAGE_MANDATORY = "mandatory";
+ public static final String USAGE_OPTIONAL = "optional";
+ public static final String MAPPING_DB_TYPE_COLUMN = "column";
+ public static final String MAPPING_DB_TYPE_DYNAMIC = "dynamic";
+
+ public String getName();
+
+ public String getType();
+
+ public String getAccessMode();
+
+ public String getUsage();
+
+ public LocalizedString getDisplayName();
+
+ public LocalizedString getDescription();
+
+ public String getMappingDBType();
+
+ public String getMappingLDAPValue();
+
+ public String getMappingDBValue();
+
+ public boolean isMappedDB();
+
+ public boolean isMappedLDAP();
+ ]]>
+ </programlisting>
+ </listitem>
+
+ </itemizedlist>
+
+ <sect2>
+ <title>Way to access identity modules</title>
+ <para>
+ The best way to access identity modules is by using JNDI:
+ </para>
+ <programlisting>
+ import org.jboss.portal.identity.UserModule;
+ import org.jboss.portal.identity.RoleModule;
+ import org.jboss.portal.identity.MembershipModule;
+ import org.jboss.portal.identity.UserProfileModule;
+
+ [...]
+
+ (UserModule)new InitialContext().lookup("java:portal/UserModule");
+ (RoleModule)new InitialContext().lookup("java:portal/RoleModule");
+ (MembershipModule)new InitialContext().lookup("java:portal/MembershipModule");
+ (UserProfileModule)new InitialContext().lookup("java:portal/UserProfileModule");
+
+ </programlisting>
+ <para>
+ Another way to do this is, if you are fimiliar with JBoss Mikrokernel architecture is by obtaining
+ <emphasis role="bold">IdentityServiceController</emphasis>
+ mbean. You may want to inject it into your mbean like this:
+ </para>
+ <programlisting>
+ <![CDATA[<depends optional-attribute-name="IdentityServiceController" proxy-type="attribute">portal:service=Module,type=IdentityServiceController</depends>]]>
+ </programlisting>
+ <para>
+ or simply obtain in your code using
+ <emphasis role="bold">portal:service=Module,type=IdentityServiceController</emphasis>
+ name. Please refer to JBoss Application Server documentation if you want to learn more
+ about MBeans. Once you obtained the object you can use it:
+ </para>
+
+ <programlisting>
+ (UserModule)identityServiceController.getIdentityContext().getObject(IdentityContext.TYPE_USER_MODULE);
+ (RoleModule)identityServiceController.getIdentityContext().getObject(IdentityContext.TYPE_ROLE_MODULE);
+ (MembershipModule)identityServiceController.getIdentityContext().getObject(IdentityContext.TYPE_MEMBERSHIP_MODULE);
+ (UserProfileModule)identityServiceController.getIdentityContext().getObject(IdentityContext.TYPE_USER_PROFILE_MODULE);
+ </programlisting>
+
+ </sect2>
+ <sect2>
+ <title>API changes since 2.4</title>
+ <para>Because in JBoss Portal 2.4 there were only
+ <emphasis role="bold">UserModule</emphasis>
+ ,
+ <emphasis role="bold">RoleModule</emphasis>
+ ,
+ <emphasis role="bold">User</emphasis>
+ and
+ <emphasis role="bold">Role</emphasis>
+ interfaces some API usages changed. Here are the most important changes you will need to aply to your
+ code
+ while migrating your aplication to 2.6:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis role="bold">User</emphasis>
+ interface
+ </para>
+ <programlisting>
+ <![CDATA[
+ //Instead of: user.getEnabled()
+ userProfileModule.getProperty(user, User.INFO_USER_ENABLED);
+
+ //Instead of: user.setEnabled(value)
+ userProfileModule.setProperty(user, User.INFO_USER_ENABLED, value);
+
+ In the similar way you should change rest of methods that are missing in User interface in 2.6 by the call to the UserProfileModule?:
+
+ //Instead of: user.getProperties()
+ userProfileModule.getProperties(user);
+
+ //Instead of: user.getGivenName()
+ userProfileModule.getProperty(user, User.INFO_USER_NAME_GIVEN);
+
+ //Instead of: user.getFamilyName()
+ userProfileModule.getProperty(user, User.INFO_USER_NAME_FAMILY);
+
+ //Instead of: user.getRealEmail()
+ userProfileModule.getProperty(user, User.INFO_USER_EMAIL_REAL);
+
+ //Instead of: user.getFakeEmail()
+ userProfileModule.getProperty(user, User.INFO_USER_EMAIL_FAKE);
+
+ //Instead of: user.getRegistrationDate()
+ userProfileModule.getProperty(user, User.INFO_USER_REGISTRATION_DATE);
+
+ //Instead of: user.getViewRealEmail()
+ userProfileModule.getProperty(user, User.INFO_USER_VIEW_EMAIL_VIEW_REAL);
+
+ //Instead of: user.getPreferredLocale()
+ userProfileModule.getProperty(user, User.INFO_USER_LOCALE);
+
+ //Instead of: user.getSignature()
+ userProfileModule.getProperty(user, User.INFO_USER_SIGNATURE);
+
+ //Instead of: user.getLastVisitDate()
+ userProfileModule.getProperty(user, User.INFO_USER_LAST_LOGIN_DATE);
+
+ ]]>
+ </programlisting>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">RoleModule</emphasis>
+ interface
+ </para>
+ <programlisting>
+ <![CDATA[
+ //Instead of
+ //RoleModule.findRoleMembers(String roleName, int offset, int limit, String userNameFilter) throws IdentityException;
+ membershipModule.findRoleMembers(String roleName, int offset, int limit, String userNameFilter)
+
+ //Instead of
+ //RoleModule.setRoles(User user, Set roles) throws IdentityException;
+ membershipModule.assignRoles(User user, Set roles)
+
+ //Instead of
+ //RoleModule.getRoles(User user) throws IdentityException;
+ membershipModule.getRoles(User user)
+
+ ]]>
+ </programlisting>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+ </sect1>
+
+
+</chapter>
Added: docs/trunk/referenceGuide/en/modules/sso.xml
===================================================================
--- docs/trunk/referenceGuide/en/modules/sso.xml (rev 0)
+++ docs/trunk/referenceGuide/en/modules/sso.xml 2007-01-30 22:33:11 UTC (rev 6128)
@@ -0,0 +1,13 @@
+<chapter id="sso">
+ <chapterinfo>
+ <author>
+ <firstname>Boleslaw</firstname>
+ <surname>Dawidowicz</surname>
+ <email>boleslaw.dawidowicz at jboss dot com</email>
+ </author>
+ </chapterinfo>
+ <title>Authentication</title>
+ <para>This chapter describes how to setup SSO in JBoss Portal</para>
+
+
+</chapter>
17 years, 3 months
JBoss Portal SVN: r6127 - docs/trunk/referenceGuide/en.
by portal-commits@lists.jboss.org
Author: bdaw
Date: 2007-01-30 17:32:42 -0500 (Tue, 30 Jan 2007)
New Revision: 6127
Modified:
docs/trunk/referenceGuide/en/master.xml
Log:
some initial work on identity, and placeholders for authentication and sso chapters
Modified: docs/trunk/referenceGuide/en/master.xml
===================================================================
--- docs/trunk/referenceGuide/en/master.xml 2007-01-30 15:49:04 UTC (rev 6126)
+++ docs/trunk/referenceGuide/en/master.xml 2007-01-30 22:32:42 UTC (rev 6127)
@@ -16,6 +16,9 @@
<!ENTITY CMS SYSTEM "modules/cmsPortlet.xml">
<!ENTITY navtabs SYSTEM "modules/navtabs.xml">
<!ENTITY themeandlayouts SYSTEM "modules/themeandlayouts.xml">
+ <!ENTITY identity SYSTEM "modules/identity.xml">
+ <!ENTITY authentication SYSTEM "modules/authentication.xml">
+ <!ENTITY sso SYSTEM "modules/sso.xml">
<!ENTITY clustering SYSTEM "modules/clustering.xml">
<!ENTITY wsrp SYSTEM "modules/wsrp.xml">
<!ENTITY security SYSTEM "modules/security.xml">
@@ -62,6 +65,9 @@
<!-- CMS --> &CMS;
<!-- NavTabs --> &navtabs;
<!-- theme/layout api --> &themeandlayouts;
+ <!-- Identity --> &identity;
+ <!-- Authentication --> &authentication;
+ <!-- SSO --> &sso;
<!-- troubleshooting FAQ--> &troubleshooting;
</book>
17 years, 3 months
JBoss Portal SVN: r6126 - trunk/core/src/main/org/jboss/portal/test/core/state.
by portal-commits@lists.jboss.org
Author: julien(a)jboss.com
Date: 2007-01-30 10:49:04 -0500 (Tue, 30 Jan 2007)
New Revision: 6126
Modified:
trunk/core/src/main/org/jboss/portal/test/core/state/ProducerTestCase.java
Log:
minor update of test names on ProducerTestCase
Modified: trunk/core/src/main/org/jboss/portal/test/core/state/ProducerTestCase.java
===================================================================
--- trunk/core/src/main/org/jboss/portal/test/core/state/ProducerTestCase.java 2007-01-30 15:43:16 UTC (rev 6125)
+++ trunk/core/src/main/org/jboss/portal/test/core/state/ProducerTestCase.java 2007-01-30 15:49:04 UTC (rev 6126)
@@ -410,7 +410,7 @@
}
*/
- public void testDestroyPortletWithinTx() throws Exception
+ public void testDestroyCCPWithinTx() throws Exception
{
// Clone a POP 2 times
TransactionAssert.beginTransaction();
@@ -639,7 +639,7 @@
}
/** todo : should check the portlet metadata as well */
- public void testGetPortlet() throws Exception
+ public void testGetCCP() throws Exception
{
// Clone a POP
TransactionAssert.beginTransaction();
17 years, 3 months
JBoss Portal SVN: r6125 - in trunk/core: src/main/org/jboss/portal/test/core/state and 1 other directory.
by portal-commits@lists.jboss.org
Author: julien(a)jboss.com
Date: 2007-01-30 10:43:16 -0500 (Tue, 30 Jan 2007)
New Revision: 6125
Modified:
trunk/core/build.xml
trunk/core/src/main/org/jboss/portal/test/core/state/ProducerTestCase.java
Log:
- make ProducerTestCase tearDown() called
- enable tests to run on ProducerTestCase
Modified: trunk/core/build.xml
===================================================================
--- trunk/core/build.xml 2007-01-30 13:36:59 UTC (rev 6124)
+++ trunk/core/build.xml 2007-01-30 15:43:16 UTC (rev 6125)
@@ -549,6 +549,7 @@
</x-sysproperty>
<x-test>
+<!--
<zest todir="${test.reports}" name="org.jboss.portal.test.core.model.portal.PortalObjectContainerTestCase"
outfile="TEST-PortalObjectContainerTestCase">
<parameter name="CacheNaturalId" value="true"/>
@@ -577,18 +578,23 @@
<parameter name="CloneOnCreate" value="false"/>
<parameter name="CacheNaturalId" value="true"/>
</zest>
+-->
<zest todir="${test.reports}" name="org.jboss.portal.test.core.state.ProducerTestCase"
outfile="TEST-ProducerTestCase">
</zest>
+<!--
<zest todir="${test.reports}" name="org.jboss.portal.test.core.state.RegistrationPersistenceManagerTestCase"
outfile="TEST-RegistrationPersistenceManagerTestCase">
</zest>
+-->
+<!--
<test todir="${test.reports}"
name="org.jboss.portal.test.core.deployment.JBossApplicationMetaDataFactoryTestCase"/>
<test todir="${test.reports}"
name="org.jboss.portal.test.core.model.portal.PortalObjectPermissionTestCase"/>
<test todir="${test.reports}"
name="org.jboss.portal.test.core.model.portal.PortalObjectIdTestCase"/>
+-->
</x-test>
<x-classpath>
<pathelement location="${build.lib}/portal-core-lib.jar"/>
@@ -665,4 +671,16 @@
</junit>
</target>
+
+ <target name="reports" depends="init">
+ <mkdir dir="${build.reports}"/>
+ <property name="test.reports" value="${module.output}/tests"/>
+ <junitreport todir="${build.reports}">
+ <fileset dir="${test.reports}">
+ <include name="TEST-*.xml"/>
+ </fileset>
+ <report format="frames" todir="${build.reports}/html"/>
+ </junitreport>
+ </target>
+
</project>
Modified: trunk/core/src/main/org/jboss/portal/test/core/state/ProducerTestCase.java
===================================================================
--- trunk/core/src/main/org/jboss/portal/test/core/state/ProducerTestCase.java 2007-01-30 13:36:59 UTC (rev 6124)
+++ trunk/core/src/main/org/jboss/portal/test/core/state/ProducerTestCase.java 2007-01-30 15:43:16 UTC (rev 6125)
@@ -43,6 +43,7 @@
import org.jboss.portal.portlet.NoSuchPortletException;
import org.jboss.portal.portlet.Portlet;
import org.jboss.portal.portlet.PortletContext;
+import org.jboss.portal.portlet.info.MetaInfo;
import org.jboss.portal.portlet.invocation.ActionInvocation;
import org.jboss.portal.portlet.invocation.PortletInvocation;
import org.jboss.portal.portlet.invocation.response.PortletInvocationResponse;
@@ -183,8 +184,8 @@
portletContainer.addPortlet("SimplePortlet", new PortletSupport()
{
{
- PreferencesInfoSupport prefs = info.getPreferencesSupport();
- prefs.addPreference("abc", new StringValue("def"));
+ info.getPreferencesSupport().addPreference("abc", new StringValue("def"));
+ info.getMetaSupport().setDisplayName("SimplePortlet");
}
public PortletInvocationResponse invoke(PortletInvocation invocation)
@@ -248,7 +249,7 @@
});
}
- protected void tearDown() throws Exception
+ public void tearDown() throws Exception
{
// Cleanup any pending transaction
TransactionAssert.endTransaction();
@@ -309,7 +310,7 @@
// todo check state
}
- public void _testCloneNullPortletWithinTx() throws Exception
+ public void testCloneNullPortletWithinTx() throws Exception
{
try
{
@@ -323,7 +324,7 @@
}
}
- public void _testCloneExistingPortletWithinTx() throws Exception
+ public void testCloneExistingPortletWithinTx() throws Exception
{
// Clone a POP
TransactionAssert.beginTransaction();
@@ -371,7 +372,7 @@
TransactionAssert.commitTransaction();
}
- public void _testDestroyNonExistingPortletWithinTx() throws Exception
+ public void testDestroyNonExistingPortletWithinTx() throws Exception
{
TransactionAssert.beginTransaction();
List failures = producer.destroyClones(Collections.singletonList(PortletContext.createPortletContext("_1")));
@@ -379,7 +380,7 @@
TransactionAssert.commitTransaction();
}
- public void _testDestroyNullPortletWithinTx() throws Exception
+ public void testDestroyNullPortletWithinTx() throws Exception
{
try
{
@@ -409,7 +410,7 @@
}
*/
- public void _testDestroyPortletWithinTx() throws Exception
+ public void testDestroyPortletWithinTx() throws Exception
{
// Clone a POP 2 times
TransactionAssert.beginTransaction();
@@ -448,7 +449,7 @@
TransactionAssert.commitTransaction();
}
- public void _testInvokeCloneBeforeWritePOPWithinTx() throws Exception
+ public void testInvokeCloneBeforeWritePOPWithinTx() throws Exception
{
TransactionAssert.beginTransaction();
PortletInvocation action = new ActionInvocation(new ActionContextImpl(Mode.VIEW));
@@ -474,7 +475,7 @@
TransactionAssert.commitTransaction();
}
- public void _testInvokeReadWritePOPWithinTx() throws Exception
+ public void testInvokeReadWritePOPWithinTx() throws Exception
{
TransactionAssert.beginTransaction();
PortletInvocation action = new ActionInvocation(new ActionContextImpl(Mode.VIEW));
@@ -492,7 +493,7 @@
TransactionAssert.commitTransaction();
}
- public void _testInvokeReadOnlyPOPWithinTx() throws Exception
+ public void testInvokeReadOnlyPOPWithinTx() throws Exception
{
TransactionAssert.beginTransaction();
PortletInvocation action = new ActionInvocation(new ActionContextImpl(Mode.VIEW));
@@ -510,7 +511,7 @@
TransactionAssert.commitTransaction();
}
- public void _testInvokeCloneBeforeWriteCCPWithinTx() throws Exception
+ public void testInvokeCloneBeforeWriteCCPWithinTx() throws Exception
{
TransactionAssert.beginTransaction();
PortletContext cloningPortletId = producer.createClone(PortletContext.createPortletContext("CloningPortlet"));
@@ -549,7 +550,7 @@
TransactionAssert.commitTransaction();
}
- public void _testInvokeReadWriteCCPWithinTx() throws Exception
+ public void testInvokeReadWriteCCPWithinTx() throws Exception
{
TransactionAssert.beginTransaction();
PortletContext cloningPortletId = producer.createClone(PortletContext.createPortletContext("CloningPortlet"));
@@ -579,7 +580,7 @@
TransactionAssert.commitTransaction();
}
- public void _testInvokeReadOnlyCCPWithinTx() throws Exception
+ public void testInvokeReadOnlyCCPWithinTx() throws Exception
{
TransactionAssert.beginTransaction();
PortletContext cloneFailedCloningPortletId = producer.createClone(PortletContext.createPortletContext("CloneFailedCloningPortlet"));
@@ -601,7 +602,7 @@
TransactionAssert.commitTransaction();
}
- public void _testInvokeCloneBeforeWritePOPWithinTxThrowsException() throws Exception
+ public void testInvokeCloneBeforeWritePOPWithinTxThrowsException() throws Exception
{
TransactionAssert.beginTransaction();
PortletInvocation action = new ActionInvocation(new ActionContextImpl(Mode.VIEW));
@@ -638,28 +639,30 @@
}
/** todo : should check the portlet metadata as well */
- public void _testGetPortlet() throws Exception
+ public void testGetPortlet() throws Exception
{
// Clone a POP
TransactionAssert.beginTransaction();
- PortletContext cloneId = producer.createClone(PortletContext.createPortletContext("SimplePortlet"));
+ PortletContext cloneContext = producer.createClone(PortletContext.createPortletContext("SimplePortlet"));
TransactionAssert.commitTransaction();
//
TransactionAssert.beginTransaction();
- Portlet portlet = producer.getPortlet(PortletContext.createPortletContext(cloneId.getId()));
- assertEquals("SimplePortlet", portlet.getContext().getId());
+ Portlet portlet = producer.getPortlet(cloneContext);
+ assertEquals(cloneContext, portlet.getContext());
+ assertEquals("SimplePortlet", portlet.getInfo().getMeta().getMetaValue(MetaInfo.DISPLAY_NAME).getDefaultString());
TransactionAssert.commitTransaction();
// Clone the modified CCP
TransactionAssert.beginTransaction();
- PortletContext cloneCloneId = producer.createClone(cloneId);
+ PortletContext cloneCloneContext = producer.createClone(cloneContext);
TransactionAssert.commitTransaction();
//
TransactionAssert.beginTransaction();
- portlet = producer.getPortlet(PortletContext.createPortletContext(cloneCloneId.getId()));
- assertEquals("SimplePortlet", portlet.getContext().getId());
+ portlet = producer.getPortlet(cloneCloneContext);
+ assertEquals(cloneCloneContext, portlet.getContext());
+ assertEquals("SimplePortlet", portlet.getInfo().getMeta().getMetaValue(MetaInfo.DISPLAY_NAME).getDefaultString());
TransactionAssert.commitTransaction();
}
17 years, 3 months