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>(a)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>(a)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>(a)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>(a)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>(a)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>(a)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>(a)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">(a)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>(a)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>(a)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>(a)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>(a)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>(a)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>(a)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>(a)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">(a)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
-@NameTemplate({@Property(key="service", value="cache"),
@Property(key="name", value="{Name}")})
-@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
+@NameTemplate({@Property(key="service",
value="cache"), @Property(key="name",
value="{Name}")})
+@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>