- Not all resources can be scoped to individual virtual portals. For example, all themes and skins are available to all virtual portals without restrictions. Credential vault, portlet services, and portal services are also common for an entire portal installation. They cannot be scoped to an individual virtual portal.
- The settings which are defined in the portal property files apply for the entire portal installation. You cannot specify separate settings for individual virtual portals.
- If you want to make use of the single signon feature that is provided by WebSphere Application Server, you have to use the same common domain suffix for all virtual portals.
- Portal search, personalization, and templates, are not aware of virtual portals.
- There are no virtual portal specific enhancements to the published portal commands and application programming interfaces.
- A URL mapping that is defined for a resource in a particular virtual portal must use the same URL context as the friendly URL context for that virtual portal itself. Example: In a virtual portal that uses the friendly URL mapping wps/portal/vp_1, all URL mappings for portal resources must start with wps/portal/vp_1, for example wps/portal/vp_1/url_1 and wps/portal/vp_1/url_2. Within this virtual portal a URL mapping such as wps/portal/url_1 is not valid, as the portion vp_1 of the URL Context is missing.
- All virtual portals on a portal installation share a common logging and tracing.
- You cannot create custom URLs in one virtual portal that address portal resource in another virtual portal. The reason is that both object IDs and unique names relate to resources of the local virtual portal. For details about how to create URLs refer to Creating custom links to portlets and pages.
Resources that are nots coped at Virtual portal level
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment