[jboss-cvs] jboss-portal-docs/referenceGuide/en/modules ...

Chris Laprun chris.laprun at jboss.com
Wed Aug 9 19:10:37 EDT 2006


  User: claprun 
  Date: 06/08/09 19:10:37

  Modified:    referenceGuide/en/modules  wsrp.xml
  Log:
  More improvements to the doc: added mini tutorial and reworked some parts for better flow.
  
  Revision  Changes    Path
  1.9       +108 -21   jboss-portal-docs/referenceGuide/en/modules/wsrp.xml
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: wsrp.xml
  ===================================================================
  RCS file: /cvsroot/jboss/jboss-portal-docs/referenceGuide/en/modules/wsrp.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -b -r1.8 -r1.9
  --- wsrp.xml	9 Aug 2006 17:05:38 -0000	1.8
  +++ wsrp.xml	9 Aug 2006 23:10:37 -0000	1.9
  @@ -80,7 +80,41 @@
         </para>
   
         <para>Here, the portlet named "BasicPortlet" is specified as being remotable. The "remotable" element is optional.</para>
  -      <para>todo: explain how to set default remotable.</para>
  +
  +      <para>
  +         It is also possible to specify that all the portlets declared within a given <emphasis>jboss-portlet.xml</emphasis>
  +         file have a specific "remotable" status by default. Usually, this feature will be used to remotely expose
  +         several portlets without having to specify the status for all the declared portlets. Let's look at an example:
  +      </para>
  +      <para>
  +         <programlisting>
  +            <![CDATA[
  +<portlet-app>
  +   <remotable>true</remotable>
  +   <portlet>
  +      <portlet-name>RemotelyExposedPortlet</portlet-name>
  +      ...
  +   </portlet>
  +   <portlet>
  +      <portlet-name>NotRemotelyExposedPortlet</portlet-name>
  +      <remotable>false</remotable>
  +      ...
  +   </portlet>
  +</portlet-app>]]>
  +         </programlisting>
  +      </para>
  +
  +      <para>
  +         In the example above, we defined two portlets with a default "remotable" status set to true. This means that
  +         all portlets defined in this descriptor are, by default, exposed remotely by JBoss Portal's WSRP producer.
  +         Note, however, that it is possible to override the default behavior by adding a <emphasis>remotable</emphasis>
  +         element to a portlet description. In that case, the "remotable" status defined by the portlet takes precedence
  +         over the default. In the example above, the <emphasis>RemotelyExposedPortlet</emphasis> inherits the "remotable"
  +         status defined by default since it does not specify a <emphasis>remotable</emphasis> element in its description.
  +         The <emphasis>NotRemotelyExposedPortlet</emphasis>, however, overrides the default behavior and is not remotely
  +         exposed. Note that in the absence of a top-level <emphasis>remotable</emphasis> element, portlets are NOT
  +         remotely exposed.
  +      </para>
      </sect1>
   
      <sect1>
  @@ -115,16 +149,78 @@
               a single <emphasis>-wsrp.xml</emphasis> file or use one file per producer.
            </para>
            <para>
  +            JBoss Portal's producer exposes its information to the Portal itself as a default consumer with the
  +            identifier <emphasis>self</emphasis>. That means that all the remotable portlets
  +            are also exposed as remote portlets in the portal. The <emphasis>portal-wsrp.sar</emphasis> file contains the
  +            file <emphasis>default-wsrp.xml</emphasis> that contains this default producer. This file can be edited or
  +            removed if needed.
  +         </para>
  +         <para>
               Once a remote producer has been configured in a <emphasis>-wsrp.xml</emphasis> file, it becomes available
               in the list of portlet provider in the Management portlet on the Admin page of JBoss Portal. You can then
               examine the list of portlets that are exposed by this producer and configure the portlets just like you
               would for local portlets.
               <note>
  -               As of 2.4, the Portlet Management interface of WSRP is <emphasis role="bold">NOT</emphasis> supported.
  -               It is therefore not possible to clone and configure portlets on the consumer side. This will be supported
  -               in 2.6.
  +               As of 2.4, the optional Portlet Management interface of WSRP is <emphasis role="bold">NOT</emphasis>
  +               supported. It is therefore not possible to clone and configure portlets on the consumer side. This will
  +               be supported in 2.6.
               </note>
            </para>
  +         <para>
  +            Let's see how it works step by step. Let's create a <emphasis>public-bea-wsrp.xml</emphasis> file as
  +            follows:
  +            <programlisting>
  +               <![CDATA[
  +<deployments>
  +   <deployment>
  +      <wsrp-producer>
  +         <producer-id>bea</producer-id>
  +         <expiration-cache>120</expiration-cache>
  +         <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
  +         <registration-data>
  +            <consumer-name>JBoss Portal 2.4 Test</consumer-name>
  +            <property>
  +               <name>registration/consumerRole</name>
  +               <lang>en</lang>
  +               <value>public</value>
  +            </property>
  +         </registration-data>
  +      </wsrp-producer>
  +   </deployment>
  +</deployments>]]>
  +            </programlisting>
  +            This producer descriptor gives access to BEA's public WSRP producer. We will look at the details of the
  +            different elements later. Note for now the <emphasis>producer-id</emphasis> element with a "bea" value. Put
  +            this file in the deploy directory and start the server (with JBoss Portal and its WSRP service deployed).
  +         </para>
  +         <para>
  +            Let's now look at the Admin page and the management portlet. Click on the "Portlets" link at the top to
  +            manage the portlets. Once this is done, look at the list of available portlet providers. If all went well,
  +            you should see something similar to this:
  +
  +            <mediaobject>
  +               <imageobject>
  +                  <imagedata fileref="images/wsrp/portlets.png" format="png" align="center" valign="middle"/>
  +               </imageobject>
  +            </mediaobject>
  +         </para>
  +         <para>
  +            We have 3 available portlet providers: <emphasis>local, self</emphasis> and <emphasis>bea</emphasis>. The
  +            "local" portlet provider exposes all the portlets deployed in this particular instance of Portal. The
  +            "self" provider is the default WSRP consumer bundled with Portal that consumes the portlets exposed by the
  +            default WSRP producer. The "bea" provider corresponds to BEA's public producer we just configured. Select it
  +            and click on "Change portlet provider". You should now see something similar to:
  +
  +            <mediaobject>
  +               <imageobject>
  +                  <imagedata fileref="images/wsrp/bea.png" format="png" align="center" valign="middle"/>
  +               </imageobject>
  +            </mediaobject>
  +         </para>
  +         <para>
  +            From there on out, you should be able to configure the portlet just as any other, baring the restriction
  +            that the WSRP Portlet Management interface is not yet supported in 2.4.
  +         </para>
         </sect2>
   
         <sect2>
  @@ -180,11 +276,13 @@
            is defined by the <emphasis role="bold">&lt;expiration-cache&gt;</emphasis> element which specifies the
               refreshing period in seconds.</para>
   
  -         <para>Additionally, some producers require consumers to register with them before authorizing them to access their
  -            offered portlets. JBoss Portal currently only supports a very basic subset of in-band registration and it is thus
  -      possible to provide required registration information in the producer configuration so that the Portal consumer
  -      can register with the remote producer when required. <note>At this time, though, only simple String properties
  -      are supported and it is not possible to configure complex registration data.</note></para>
  +         <para>Additionally, some producers require consumers to register with them before authorizing them to access
  +            their offered portlets. JBoss Portal currently only supports a very basic subset of in-band registration
  +            and it is thus possible to provide required registration information in the producer configuration so that
  +            the Portal consumer can register with the remote producer when required.
  +            <note>At this time, though, only simple String properties are supported and it is not possible to configure
  +               complex registration data.</note>
  +         </para>
   
            <para>Registration configuration is done via the <emphasis role="bold">&lt;registration-datat&gt;</emphasis>
               element. We need to provide a consumer name (via the <emphasis role="bold">&lt;consumer-name&gt;</emphasis>
  @@ -251,15 +349,4 @@
            </para>
         </sect2>
      </sect1>
  -
  -   <sect1>
  -      <title>Default consumer example</title>
  -      <para>
  -         JBoss Portal's producer exposes its information to the Portal itself as a default consumer with the
  -         identifier <emphasis>self</emphasis>. That means that all the remotable portlets
  -         are also exposed as remote portlets in the portal. The <emphasis>portal-wsrp.sar</emphasis> file contains the
  -         file <emphasis>default-wsrp.xml</emphasis> that contains this default producer. This file can be edited or
  -         removed if needed.
  -      </para>
  -   </sect1>
   </chapter>
  
  
  



More information about the jboss-cvs-commits mailing list