[gatein-commits] gatein SVN: r9175 - in epp/docs/branches/6.0/Reference_Guide/en-US: modules/Advanced/Foundations and 5 other directories.
do-not-reply at jboss.org
do-not-reply at jboss.org
Thu Feb 21 00:42:57 EST 2013
Author: jaredmorgs
Date: 2013-02-21 00:42:57 -0500 (Thu, 21 Feb 2013)
New Revision: 9175
Modified:
epp/docs/branches/6.0/Reference_Guide/en-US/Reference_Guide.ent
epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Advanced_Concepts.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Configuring_Services.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Management.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/System_Properties.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/portlet_development.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Standard.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/jdbc-data-container-config.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/statistics.xml
Log:
BZ#911516 - incorporated comments 1 to 3 in the ticket.
Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Reference_Guide.ent
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/Reference_Guide.ent 2013-02-20 07:36:21 UTC (rev 9174)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/Reference_Guide.ent 2013-02-21 05:42:57 UTC (rev 9175)
@@ -18,3 +18,4 @@
<!ENTITY VY "6.0">
<!ENTITY VZ "6.0.0">
<!ENTITY WSRP_VERSION "2.2.2.Final">
+<!ENTITY JCR_VERSION "1.15.1-CP01-redhat-1">
Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Advanced_Concepts.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Advanced_Concepts.xml 2013-02-20 07:36:21 UTC (rev 9174)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Advanced_Concepts.xml 2013-02-21 05:42:57 UTC (rev 9175)
@@ -333,7 +333,7 @@
</listitem>
<listitem>
<para>
- No file exists at the previous path, we then assume that the path cans be interpreted by the <envar>ConfigurationManager</envar>.
+ No file exists at the previous path, we then assume that the path can be interpreted by the <envar>ConfigurationManager</envar>.
</para>
</listitem>
</orderedlist>
@@ -342,7 +342,7 @@
</listitem>
<listitem>
<para>
- The path contains a prefix, we then assume that the path cans be interpreted by the <envar>ConfigurationManager</envar>.
+ The path contains a prefix, we then assume that the path can be interpreted by the <envar>ConfigurationManager</envar>.
</para>
</listitem>
</orderedlist></entry>
@@ -436,7 +436,7 @@
</listitem>
<listitem>
<para>
- No file exists at the previous path, we then assume that the path cans be interpreted by the <envar>ConfigurationManager</envar>.
+ No file exists at the previous path, we then assume that the path can be interpreted by the <envar>ConfigurationManager</envar>.
</para>
</listitem>
</orderedlist>
@@ -445,7 +445,7 @@
</listitem>
<listitem>
<para>
- The path contains a prefix, we then assume that the path cans be interpreted by the <envar>ConfigurationManager</envar>.
+ The path contains a prefix, we then assume that the path can be interpreted by the <envar>ConfigurationManager</envar>.
</para>
</listitem>
</orderedlist></entry>
Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Configuring_Services.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Configuring_Services.xml 2013-02-20 07:36:21 UTC (rev 9174)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Configuring_Services.xml 2013-02-21 05:42:57 UTC (rev 9175)
@@ -9,7 +9,7 @@
The eXo Kernel uses dependency injection to create services based on <filename>configuration.xml</filename> configuration files. The location of the configuration files determines if services are placed into the <literal>RootContainer</literal> scope, or into the <literal>PortalContainer</literal> scope.
</para>
<para>
- When creating a service, you also should declare its existence to the <emphasis role="bold">Container</emphasis>. This fan be done by creating a simple configuration file.
+ When creating a service, you also should declare its existence to the <emphasis role="bold">Container</emphasis>. This can be done by creating a simple configuration file.
</para>
<para>
Copy the following code to a <filename>configuration.xml</filename> file and save this file in a <filename>/conf</filename> subdirectory of your service base folder. The container looks for a <filename>/conf/configuration.xml</filename> file in each jar-file.
@@ -744,7 +744,7 @@
</listitem>
</itemizedlist>
<para>
- If you open the "portal/trunk/web/portal/src/main/webapp/WEB-INF/conf.configuration.xml" you will see that it consists only of imports:
+ If you open the <filename>portal/trunk/web/portal/src/main/webapp/WEB-INF/conf/configuration.xml</filename> you will see that it consists only of imports:
</para>
<programlisting language="XML" role="XML"><import>war:/conf/common/common-configuration.xml</import>
<import>war:/conf/common/logs-configuration.xml</import>
Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Management.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Management.xml 2013-02-20 07:36:21 UTC (rev 9174)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/Management.xml 2013-02-21 05:42:57 UTC (rev 9175)
@@ -1,130 +1,103 @@
-<?xml version='1.0' encoding='utf-8' ?>
+<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "Reference_Guide.ent">
%BOOK_ENTITIES;
]>
<section id="sect-Reference_Guide-Manageability">
- <title>Manageability</title>
- <section id="sect-Reference_Guide-Manageability-Introduction">
- <title>Introduction</title>
- <para>
- The kernel has a framework for exposing a management view of the various sub systems of the platform. The management view is a lose term for defining how we can access relevant information about the system and how we can apply management operations. JMX is the de facto standard for exposing a management view in the Java Platform but we take in consideration other kind of views such as REST web services. Therefore, the framework is not tied to JMX, yet it provides a JMX part to define more precisely details related to the JMX management view. The legacy framework is still in use but is deprecated in favor of the new framework as it is less tested and less efficient. It will be removed by sanitization in the future.
- </para>
-
- </section>
-
- <section id="sect-Reference_Guide-Manageability-Managed_framework_API">
- <title>Managed framework API</title>
- <para>
- The managed frameworks defines an API for exposing a management view of objects. The API is targeted for internal use and is not a public API. The framework leverages Java 5 annotations to describe the management view from an object.
- </para>
- <section id="sect-Reference_Guide-Managed_framework_API-Annotations">
- <title>Annotations</title>
- <section id="sect-Reference_Guide-Annotations-org.exoplatform.management.annotations.Managed_annotation">
- <title>@org.exoplatform.management.annotations.Managed annotation</title>
- <para>
- The @Managed annotates elements that wants to expose a management view to a management layer.
- </para>
- <para>
- <emphasis role="bold">@Managed for objects</emphasis>
- </para>
- <para>
- The framework will export a management view for the objects annotated.
- </para>
- <para>
- <emphasis role="bold">@Managed for getter/setter</emphasis>
- </para>
- <para>
- Defines a managed property. An annotated getter defines a read property, an annotated setter defines a write property and if matching getter/setter are annotated it defines a read/write property.
- </para>
- <para>
- <emphasis role="bold">@Managed on method</emphasis>
- </para>
- <para>
- Defines a managed operation.
- </para>
-
- </section>
-
- <section id="sect-Reference_Guide-Annotations-org.exoplatform.management.annotations.ManagedDescription">
- <title>@org.exoplatform.management.annotations.ManagedDescription</title>
- <para>
- The @ManagedDescription annotation provides a description of a managed element. It is valid to annotated object or methods. It takes as sole argument a string that is the description value.
- </para>
-
- </section>
-
- <section id="sect-Reference_Guide-Annotations-org.exoplatform.management.annotations.ManagedName">
- <title>@org.exoplatform.management.annotations.ManagedName</title>
- <para>
- The @ManagedName annotation provides an alternative name for managed properties. It is used to accomodate legacy methods of an object that can be renamed for compatibility reasons. It takes as sole argument a string that is the name value.
- </para>
-
- </section>
-
- <section id="sect-Reference_Guide-Annotations-org.exoplatform.management.annotations.ManagedBy">
- <title>@org.exoplatform.management.annotations.ManagedBy</title>
- <para>
- The @ManagedBy annotation defines a delegate class for exposing a management view. The sole argument of the annotation are class literals. The delegate class must provide a constructor with the managed object as argument.
- </para>
-
- </section>
-
-
- </section>
-
-
- </section>
-
- <section id="sect-Reference_Guide-Manageability-JMX_Management_View">
- <title>JMX Management View</title>
- <section id="sect-Reference_Guide-JMX_Management_View-JMX_Annotations">
- <title>JMX Annotations</title>
- <section id="sect-Reference_Guide-JMX_Annotations-org.exoplatform.management.jmx.annotations.Property_annotation">
- <title>@org.exoplatform.management.jmx.annotations.Property annotation</title>
- <para>
- The @Property annotation is used to within other annotations such as @NameTemplate or @NamingContext. It should be seen as a structural way for a list of properties. A property is made of a key and a value. The value can either be a string literal or it can be surrounded by curly brace to be a dynamic property. A dynamic property is resolved against the instance of the object at runtime.
- </para>
-
- </section>
-
- <section id="sect-Reference_Guide-JMX_Annotations-org.exoplatform.management.jmx.annotations.NameTemplate_annotation">
- <title>@org.exoplatform.management.jmx.annotations.NameTemplate annotation</title>
- <para>
- The @NameTemplate defines a template that is used at registration time of a managed object to create the JMX object name. The template is formed of properties.
- </para>
-
-<programlisting language="Java" role="Java">@NameTemplate({
- @Property(key="container", value="workspace"),
- @Property(key="name", value="{Name}")})</programlisting>
-
- </section>
-
- <section id="sect-Reference_Guide-JMX_Annotations-org.exoplatform.management.jmx.annotations.NamingContext_annotation">
- <title>@org.exoplatform.management.jmx.annotations.NamingContext annotation</title>
- <para>
- The @NamingContext annotations defines a set of properties which are used within a management context. It allows to propagate properties down to managed objects which are defined by an object implementing the ManagementAware interface. The goal is to scope different instances of the same class that would have the same object name otherwise.
- </para>
-
-<programlisting language="Java" role="Java">@NamingContext(@Property(key="workspace", value="{Name}"))</programlisting>
-
- </section>
-
-
- </section>
-
-
- </section>
-
- <section id="sect-Reference_Guide-Manageability-Example">
- <title>Example</title>
- <section id="sect-Reference_Guide-Example-CacheService_example">
- <title>CacheService example</title>
- <para>
- The cache service delegates most of the work to the CacheServiceManaged class by using the @ManagedBy annotation. At runtime when a new cache is created, it calls the CacheServiceManaged class in order to let the CacheServiceManaged object register the cache.
- </para>
-
-<programlisting language="Java" role="Java">@ManagedBy(CacheServiceManaged.class)
+ <title>Manageability</title>
+ <section id="sect-Reference_Guide-Manageability-Introduction">
+ <title>Introduction</title>
+ <para>
+ The kernel has a framework for exposing a management view of the various sub systems of the platform. The management view is a lose term for defining how we can access relevant information about the system and how we can apply management operations. JMX is the de facto standard for exposing a management view in the Java Platform but we take in consideration other kind of views such as REST web services. Therefore, the framework is not tied to JMX, yet it provides a JMX part to define more precisely details related to the JMX management view. The legacy framework is still in use but is deprecated in favor of the new framework as it is less tested and less efficient. It will be removed by sanitization in the future.
+ </para>
+ </section>
+ <section id="sect-Reference_Guide-Manageability-Managed_framework_API">
+ <title>Managed framework API</title>
+ <para>
+ The managed frameworks define an API for exposing a management view of objects. The API is targeted for internal use and is not a public API. The framework leverages Java 5 annotations to describe the management view from an object.
+ </para>
+ <section id="sect-Reference_Guide-Managed_framework_API-Annotations">
+ <title>Annotations</title>
+ <section id="sect-Reference_Guide-Annotations-org.exoplatform.management.annotations.Managed_annotation">
+ <title>@org.exoplatform.management.annotations.Managed annotation</title>
+ <para>
+ The @Managed annotates elements that wants to expose a management view to a management layer.
+ </para>
+ <para>
+ <emphasis role="bold">@Managed for objects</emphasis>
+ </para>
+ <para>
+ The framework will export a management view for the objects annotated.
+ </para>
+ <para>
+ <emphasis role="bold">@Managed for getter/setter</emphasis>
+ </para>
+ <para>
+ Defines a managed property. An annotated getter defines a read property, an annotated setter defines a write property and if matching getter/setter are annotated it defines a read/write property.
+ </para>
+ <para>
+ <emphasis role="bold">@Managed on method</emphasis>
+ </para>
+ <para>
+ Defines a managed operation.
+ </para>
+ </section>
+ <section id="sect-Reference_Guide-Annotations-org.exoplatform.management.annotations.ManagedDescription">
+ <title>@org.exoplatform.management.annotations.ManagedDescription</title>
+ <para>
+ The @ManagedDescription annotation provides a description of a managed element. It is valid to annotated object or methods. It takes as sole argument a string that is the description value.
+ </para>
+ </section>
+ <section id="sect-Reference_Guide-Annotations-org.exoplatform.management.annotations.ManagedName">
+ <title>@org.exoplatform.management.annotations.ManagedName</title>
+ <para>
+ The @ManagedName annotation provides an alternative name for managed properties. It is used to accomodate legacy methods of an object that can be renamed for compatibility reasons. It takes as sole argument a string that is the name value.
+ </para>
+ </section>
+ <section id="sect-Reference_Guide-Annotations-org.exoplatform.management.annotations.ManagedBy">
+ <title>@org.exoplatform.management.annotations.ManagedBy</title>
+ <para>
+ The @ManagedBy annotation defines a delegate class for exposing a management view. The sole argument of the annotation are class literals. The delegate class must provide a constructor with the managed object as argument.
+ </para>
+ </section>
+ </section>
+ </section>
+ <section id="sect-Reference_Guide-Manageability-JMX_Management_View">
+ <title>JMX Management View</title>
+ <section id="sect-Reference_Guide-JMX_Management_View-JMX_Annotations">
+ <title>JMX Annotations</title>
+ <section id="sect-Reference_Guide-JMX_Annotations-org.exoplatform.management.jmx.annotations.Property_annotation">
+ <title>@org.exoplatform.management.jmx.annotations.Property annotation</title>
+ <para>
+ The @Property annotation is used to within other annotations such as @NameTemplate or @NamingContext. It should be seen as a structural way for a list of properties. A property is made of a key and a value. The value can either be a string literal or it can be surrounded by curly brace to be a dynamic property. A dynamic property is resolved against the instance of the object at runtime.
+ </para>
+ </section>
+ <section id="sect-Reference_Guide-JMX_Annotations-org.exoplatform.management.jmx.annotations.NameTemplate_annotation">
+ <title>@org.exoplatform.management.jmx.annotations.NameTemplate annotation</title>
+ <para>
+ The @NameTemplate defines a template that is used at registration time of a managed object to create the JMX object name. The template is formed of properties.
+ </para>
+ <programlisting language="Java" role="Java">@NameTemplate({
+ @Property(key="container", value="workspace"),
+ @Property(key="name", value="{Name}")})</programlisting>
+ </section>
+ <section id="sect-Reference_Guide-JMX_Annotations-org.exoplatform.management.jmx.annotations.NamingContext_annotation">
+ <title>@org.exoplatform.management.jmx.annotations.NamingContext annotation</title>
+ <para>
+ The @NamingContext annotation defines a set of properties which are used within a management context. It allows to propagate properties down to managed objects which are defined by an object implementing the ManagementAware interface. The goal is to scope different instances of the same class that would have the same object name otherwise.
+ </para>
+ <programlisting language="Java" role="Java">@NamingContext(@Property(key="workspace", value="{Name}"))</programlisting>
+ </section>
+ </section>
+ </section>
+ <section id="sect-Reference_Guide-Manageability-Example">
+ <title>Example</title>
+ <section id="sect-Reference_Guide-Example-CacheService_example">
+ <title>CacheService example</title>
+ <para>
+ The cache service delegates most of the work to the CacheServiceManaged class by using the @ManagedBy annotation. At runtime when a new cache is created, it calls the CacheServiceManaged class in order to let the CacheServiceManaged object register the cache.
+ </para>
+ <programlisting language="Java" role="Java">@ManagedBy(CacheServiceManaged.class)
public class CacheServiceImpl implements CacheService {
CacheServiceManaged managed;
@@ -137,36 +110,34 @@
...
}
}</programlisting>
- <para>
- The ExoCache interface is annotated to define its management view. The @NameTemplate is used to produce object name values when ExoCache instance are registered.
- </para>
-
-<programlisting language="Java" role="Java">@Managed
- at NameTemplate({@Property(key="service", value="cache"), @Property(key="name", value="{Name}")})
- at ManagedDescription("Exo Cache")
+ <para>
+ The ExoCache interface is annotated to define its management view. The @NameTemplate is used to produce object name values when ExoCache instance are registered.
+ </para>
+ <programlisting language="Java" role="Java">@Managed
+ at NameTemplate({@Property(key="service", value="cache"), @Property(key="name", value="{Name}")})
+ at ManagedDescription("Exo Cache")
public interface ExoCache {
@Managed
- @ManagedName("Name")
- @ManagedDescription("The cache name")
+ @ManagedName("Name")
+ @ManagedDescription("The cache name")
public String getName();
@Managed
- @ManagedName("Capacity")
- @ManagedDescription("The maximum capacity")
+ @ManagedName("Capacity")
+ @ManagedDescription("The maximum capacity")
public int getMaxSize();
@Managed
- @ManagedDescription("Evict all entries of the cache")
+ @ManagedDescription("Evict all entries of the cache")
public void clearCache() throws Exception;
...
}</programlisting>
- <para>
- The CacheServiceManaged is the glue code between the CacheService and the management view. The main reason is that only exo services are registered automatically against the management view. Any other managed bean must be registered manually for now. Therefore, it needs to know about the management layer via the management context. The management context allows an object implementing the ManagementAware interface to receive a context to perform further registration of managed objects.
- </para>
-
-<programlisting language="Java" role="Java">@Managed
+ <para>
+ The CacheServiceManaged is the glue code between the CacheService and the management view. The main reason is that only exo services are registered automatically against the management view. Any other managed bean must be registered manually for now. Therefore, it needs to know about the management layer via the management context. The management context allows an object implementing the ManagementAware interface to receive a context to perform further registration of managed objects.
+ </para>
+ <programlisting language="Java" role="Java">@Managed
public class CacheServiceManaged implements ManagementAware {
/** . */
@@ -192,13 +163,6 @@
}
}
}</programlisting>
-
- </section>
-
-
- </section>
-
-
+ </section>
+ </section>
</section>
-
-
Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/System_Properties.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/System_Properties.xml 2013-02-20 07:36:21 UTC (rev 9174)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/Advanced/Foundations/System_Properties.xml 2013-02-21 05:42:57 UTC (rev 9175)
@@ -6,10 +6,10 @@
<section id="sect-Reference_Guide-System_property_configuration">
<title>System property configuration</title>
<para>
- A new property configurator service has been developed for taking care of configuring system properties from the inline kernel configuration or from specified property files.
+ A new property configuration service has been developed for taking care of configuring system properties from the inline kernel configuration or from specified property files.
</para>
<para>
- The services is scoped at the root container level because it is used by all the services in the different portal containers in the application runtime.
+ The service is scoped at the root container level because it is used by all the services in the different portal containers in the application runtime.
</para>
<section id="sect-Reference_Guide-System_property_configuration-Properties_init_param">
<title>Properties <init-param></title>
Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml 2013-02-20 07:36:21 UTC (rev 9174)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortalDevelopment/Skinning.xml 2013-02-21 05:42:57 UTC (rev 9175)
@@ -87,7 +87,7 @@
The default skin can also be configured using the portal configuration files. This allows the portal to have the new default skin ready for use when JBoss Portal Platform is first started.
</para>
<para>
- The default skin of the portal is called <literal>Default</literal>. To change this value add a <literal>skin</literal> tag in the <literal>portal.war/WEB-INF/conf/portal/portal/classic/portal.xml</literal> configuration file.
+ The default skin of the portal is called <literal>Default</literal>. To change this value add a <literal>skin</literal> tag in the <literal>JPP_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/portal/portal/classic/portal.xml</literal> configuration file.
</para>
<para>
To change the skin to <literal>MySkin</literal> you would make the following changes:
@@ -140,7 +140,7 @@
<section id="sect-Reference_Guide-The_Skin_Service-Skin_configuration">
<title>Skin configuration</title>
<para>
-JBoss Portal Platform automatically discovers web archives that contain a file descriptor for skins (<filename>WEB-INF/gatein-resources.xml</filename>). This file is responsible for specifying the portal, portlet and window decorators to be deployed into the skin service.
+JBoss Portal Platform automatically discovers web archives that contain a file descriptor for skins (<filename>JPP_HOME/gatein/gatein.ear/portal.war/WEB-INF/gatein-resources.xml</filename>). This file is responsible for specifying the portal, portlet and window decorators to be deployed into the skin service.
</para>
<para>
The full schema can be found at: <ulink url="http://www.gatein.org/xml/ns/gatein_resources_1_2" type="http"/>.
@@ -153,7 +153,7 @@
<section id="sect-Reference_Guide-The_Skin_Service-Resource_Request_Filter">
<title>Resource Request Filter</title>
<para>
- Because of JBoss Portal Platform's Right-To-Left support, all CSS files need to be retrieved through a Servlet filter and the web application needs to be configured to activate this filter. This is already done for the<literal>JPP_HOME/gatein/gatein.ear/eXoResources.war</literal> web application which contains the default skin.
+ Because of JBoss Portal Platform's Right-To-Left support, all CSS files need to be retrieved through a Servlet filter and the web application needs to be configured to activate this filter. This is already done for the <literal>JPP_HOME/gatein/gatein.ear/eXoResources.war</literal> web application which contains the default skin.
</para>
<para>
Any new web applications containing skinning CSS files will need to have the following added to their <filename>web.xml</filename> :
Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/portlet_development.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/portlet_development.xml 2013-02-20 07:36:21 UTC (rev 9174)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/PortletBridge/portlet_development.xml 2013-02-21 05:42:57 UTC (rev 9175)
@@ -24,12 +24,12 @@
<programlisting language="XML"><dependency>
<groupId>org.jboss.portletbridge</groupId>
<artifactId>portletbridge-api</artifactId>
- <version>3.1.0.Final</version>
+ <version>3.1.2.Final</version>
</dependency>
<dependency>
<groupId>org.jboss.portletbridge</groupId>
<artifactId>portletbridge-impl</artifactId>
- <version>3.1.0.Final</version>
+ <version>3.1.2.Final</version>
<scope>runtime</scope>
</dependency></programlisting>
</step>
@@ -38,7 +38,7 @@
<programlisting language="XML"><dependency>
<groupId>org.jboss.portletbridge</groupId>
<artifactId>portletbridge-extension-richfaces</artifactId>
- <version>3.1.0.Final</version>
+ <version>3.1.2.Final</version>
<scope>runtime</scope>
</dependency></programlisting>
</step>
@@ -54,7 +54,7 @@
<programlisting language="XML"><dependency>
<groupId>org.jboss.portletbridge</groupId>
<artifactId>jsf2-depchain</artifactId>
- <version>3.1.0.Final</version>
+ <version>3.1.2.Final</version>
<type>pom</type>
</dependency></programlisting>
</step>
@@ -63,13 +63,13 @@
<programlisting language="XML"><dependency>
<groupId>org.jboss.portletbridge</groupId>
<artifactId>jsf2-depchain</artifactId>
- <version>3.1.0.Final</version>
+ <version>3.1.2.Final</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>org.jboss.portletbridge</groupId>
<artifactId>richfaces4-depchain</artifactId>
- <version>3.1.0.Final</version>
+ <version>3.1.2.Final</version>
<type>pom</type>
</dependency></programlisting>
</step>
@@ -86,7 +86,7 @@
<programlisting language="XML"><dependency>
<groupId>org.jboss.portletbridge</groupId>
<artifactId>portletbridge-api</artifactId>
- <version>3.1.0.Final</version>
+ <version>3.1.2.Final</version>
<scope>provided</scope>
</dependency></programlisting>
</step>
Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Standard.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Standard.xml 2013-02-20 07:36:21 UTC (rev 9174)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/PortletDevelopment/Standard.xml 2013-02-21 05:42:57 UTC (rev 9175)
@@ -30,17 +30,17 @@
<para>
The diagram below visually represents this nesting:
</para>
-<figure>
- <title id="SpecPortalDef">Portal Specification</title>
- <mediaobject>
- <imageobject role="html">
- <imagedata width="444" align="center" scale="95" fileref="images/PortletDevelopment/Standard/SpecPortalDef.png" format="PNG"/>
- </imageobject>
- <imageobject role="fo">
- <imagedata width="444" contentwidth="140mm" align="center" fileref="images/PortletDevelopment/Standard/SpecPortalDef.png" format="PNG"/>
- </imageobject>
- </mediaobject>
-</figure>
+ <figure>
+ <title id="SpecPortalDef">Portal Specification</title>
+ <mediaobject>
+ <imageobject role="html">
+ <imagedata width="444" align="center" scale="95" fileref="images/PortletDevelopment/Standard/SpecPortalDef.png" format="PNG"/>
+ </imageobject>
+ <imageobject role="fo">
+ <imagedata width="444" contentwidth="140mm" align="center" fileref="images/PortletDevelopment/Standard/SpecPortalDef.png" format="PNG"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
</section>
<section id="sect-Reference_Guide-JSR_168_and_JSR_286_overview-Rendering_Modes">
<title>Rendering Modes</title>
@@ -208,8 +208,7 @@
Comment #2: If only the <literal>view</literal> mode is required, then only the <literal>doView</literal> method needs to be implemented. The <classname>GenericPortlet</classname> render implementation calls our implementation when the <literal>view</literal> mode is requested.
</para>
<para>
- Comment #3: Use the <methodname>RenderResponse</methodname> method to obtain a writer to be used to produce content.
- </para>
+ Comment #3: To obtain a writer that can produce content, use the <methodname>response.GetWriter()</methodname> method from the RenderResponse object. </para>
<para>
Comment #4: Write the markup to display.
</para>
@@ -323,17 +322,17 @@
</para>
</step>
</procedure>
-<figure>
- <title id="fig_output">Create New Portal Page and Add Portlet</title>
- <mediaobject>
- <imageobject role="html">
- <imagedata width="444" align="center" scale="100" fileref="images/PortletDevelopment/Standard/jsp_portlet/output.png" format="PNG"/>
- </imageobject>
- <imageobject role="fo">
- <imagedata width="444" contentwidth="120mm" align="center" fileref="images/PortletDevelopment/Standard/jsp_portlet/output.png" format="PNG"/>
- </imageobject>
- </mediaobject>
-</figure>
+ <figure>
+ <title id="fig_output">Create New Portal Page and Add Portlet</title>
+ <mediaobject>
+ <imageobject role="html">
+ <imagedata width="444" align="center" scale="100" fileref="images/PortletDevelopment/Standard/jsp_portlet/output.png" format="PNG"/>
+ </imageobject>
+ <imageobject role="fo">
+ <imagedata width="444" contentwidth="120mm" align="center" fileref="images/PortletDevelopment/Standard/jsp_portlet/output.png" format="PNG"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
<!-- Does not seem to appear any longer
<note>
<para>
@@ -437,59 +436,54 @@
<para>
In the third method, the action phase is triggered first then the render phase is triggered, which outputs some content back to the web browser based on the available render parameters.
</para>
-<figure>
+ <figure>
<title id="process">Render Phase Process</title>
- <mediaobject>
- <imageobject role="html">
- <imagedata width="444" align="center" scale="100" fileref="images/PortletDevelopment/Standard/jsp_portlet/process.png" format="PNG"/>
- </imageobject>
- <imageobject role="fo">
- <imagedata width="444" contentwidth="140mm" align="center" fileref="images/PortletDevelopment/Standard/jsp_portlet/process.png" format="PNG"/>
- </imageobject>
- </mediaobject>
-</figure>
+ <mediaobject>
+ <imageobject role="html">
+ <imagedata width="444" align="center" scale="100" fileref="images/PortletDevelopment/Standard/jsp_portlet/process.png" format="PNG"/>
+ </imageobject>
+ <imageobject role="fo">
+ <imagedata width="444" contentwidth="140mm" align="center" fileref="images/PortletDevelopment/Standard/jsp_portlet/process.png" format="PNG"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
</section>
</section>
- <section id="sect-Reference_Guide-JavaServer_Pages_Portlet_Example-JSF_example_using_the_JBoss_Portlet_Bridge">
- <title>JSF example using the JBoss Portlet Bridge</title>
- <para>
- In order to write a portlet using JSF a 'bridge' is needed. This software allows developers to write a portlet application as if it was a JSF application. The bridge then negotiates the interactions between the two layers.
+<!--DOCS NOTE - jmorgan - Commented out the JSF Example section below because the new Portlet Bridge chapter describes the bridge much better than this. --><!--<section id="sect-Reference_Guide-JavaServer_Pages_Portlet_Example-JSF_example_using_the_JBoss_Portlet_Bridge">
+ <title>JSF example using the JBoss Portlet Bridge</title>
+ <para>
+ In order to write a portlet using JSF, a 'bridge' is needed. This software allows developers to write a portlet application as if it was a JSF application. The bridge then negotiates the interactions between the two layers.
</para>
- <para>
- An example using the JBoss Portlet Bridge is available in the <filename>/jboss-jpp-<replaceable>VERSION</replaceable>-src/portal/examples/portlets/</filename> directory of the JBoss Portal Platform sources package. The configuration is slightly different from a JSP application. This example can be used as a base to configure instead of creating a new application.
+ <para> As in any JSF application, the file <literal>faces-config.xml</literal> is required. It must contain the following information:
</para>
- <para>
- As in any JSF application, the file <literal>faces-config.xml</literal> is required. It must contain the following information:
- </para>
- <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/PortletDevelopment_Standard/default253.xml" parse="text"/></programlisting>
- <para>
+ <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/PortletDevelopment_Standard/default253.xml" parse="text"/></programlisting>
+ <para>
The portlet bridge libraries must be available and are usually bundled with the <literal>WEB-INF/lib</literal> directory of the web archive.
</para>
- <para>
+ <para>
The other differences when compared to a regular portlet application are in the portlet descriptor. All the relevant details about this can be found in the JSR-329 specification that the JBoss Portlet Bridge implements.
</para>
- <example>
- <title>Portlet Descriptor Explanation</title>
- <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/PortletDevelopment_Standard/default254.xml" parse="text"/></programlisting>
- <para>
+ <example>
+ <title>Portlet Descriptor Explanation</title>
+ <programlisting language="XML" role="XML"><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../extras/PortletDevelopment_Standard/default254.xml" parse="text"/></programlisting>
+ <para>
Comment #1: All JSF portlets define <literal>javax.portlet.faces.GenericFacesPortlet</literal> as a portlet class. This class is part of the JBoss Portlet Bridge.
</para>
- <para>
+ <para>
Comment #2: This is a mandatory parameter to define what's the default page to display.
</para>
- <para>
+ <para>
Comment #3: This parameter defines which page to display on the 'edit' mode.
</para>
- <para>
+ <para>
Comment #4: This parameter defines which page to display on the 'help' mode.
</para>
- </example>
- <note>
- <title>JBoss Portlet Bridge</title>
- <para>
+ </example>
+ <note>
+ <title>JBoss Portlet Bridge</title>
+ <para>
For more information about the JBoss Portlet Bridge, see the dedicated chapter which is part of this document.
</para>
- </note>
- </section>
- </section>
+ </note>
+</section>--> </section>
</chapter>
Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/jdbc-data-container-config.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/jdbc-data-container-config.xml 2013-02-20 07:36:21 UTC (rev 9174)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/configuration/jdbc-data-container-config.xml 2013-02-21 05:42:57 UTC (rev 9175)
@@ -1,5 +1,7 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY JCR_VERSION ''>
+<!ENTITY JSR_VERSION ''>
<!ENTITY % BOOK_ENTITIES SYSTEM "Reference_Guide.ent">
%BOOK_ENTITIES;
]>
@@ -112,9 +114,9 @@
<para>
Each database software supports ANSI SQL standards but also has its own specifics. Therefore each database has its own configuration setting in the eXo JCR as a database dialect parameter. More detailed configuration of the database can be set by editing the metadata SQL-script files.
</para>
-<remark>NEEDINFO - FILE PATHS - The path needs to be updated with the equivalent path for JBoss Portal Platform instead of gatein, please see below para. New info required?</remark>
-<para>
- You can find SQL-scripts in <filename>conf/storage/</filename> directory of the <filename><replaceable>JPP_HOME</replaceable>/modules/org/gatein/lib/main/exo.jcr.component.core-<remark>VERSION</remark>.jar</filename> file .
+ <remark>NEEDINFO - FILE PATHS - The path needs to be updated with the equivalent path for JBoss Portal Platform instead of gatein, please see below para. New info required?</remark>
+ <para>
+ You can find SQL-scripts in <filename>conf/storage/</filename> directory of the <filename><replaceable>JPP_HOME</replaceable>/modules/org/gatein/lib/main/exo.jcr.component.core-&JCR_VERSION;.jar</filename> file .
</para>
<para>
The following tables show the correspondence between the scripts and databases:
@@ -245,7 +247,7 @@
If a non-ANSI node name is used, you must use a database with MultiLanguage support. Some JDBC drivers need additional parameters for establishing a Unicode friendly connection. For example under mysql it is necessary to add an additional parameter for the JDBC driver at the end of JDBC URL:
</para>
<para>
- There are preconfigured configuration files for HSQLDB. Look for these files in /conf/portal and /conf/standalone folders of the jar-file <package>exo.jcr.component.core-XXX.XXX.jar</package> or source-distribution of eXo JCR implementation.
+ There are preconfigured configuration files for HSQLDB. Look for these files in /conf/portal and /conf/standalone folders of the jar-file <package>exo.jcr.component.core-&JCR_VERSION;.jar</package> or source-distribution of eXo JCR implementation.
</para>
<example id="exam-Reference_Guide-Introduction-Example_Parameter">
<title>Example Parameter</title>
Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/statistics.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/statistics.xml 2013-02-20 07:36:21 UTC (rev 9174)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/eXoJCR/jcr/statistics.xml 2013-02-21 05:42:57 UTC (rev 9175)
@@ -300,7 +300,7 @@
</row>
<row>
<entry> getTimes </entry>
- <entry> Give the total amount of times the method has been called corresponding to the given ,category name and statistics name. The expected arguments are the name of the category of statistics (e.g. JDBCStorageConnection) and the name of the expected method or global for the global value. </entry>
+ <entry> Give the total amount of times the method has been called corresponding to the given category name and statistics name. The expected arguments are the name of the category of statistics (e.g. JDBCStorageConnection) and the name of the expected method or global for the global value. </entry>
</row>
<row>
<entry> reset </entry>
More information about the gatein-commits
mailing list