From do-not-reply at jboss.org Sun May 16 19:22:28 2010 Content-Type: multipart/mixed; boundary="===============1048035609533463323==" MIME-Version: 1.0 From: do-not-reply at jboss.org To: gatein-commits at lists.jboss.org Subject: [gatein-commits] gatein SVN: r3100 - in portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US: modules and 1 other directories. Date: Sun, 16 May 2010 19:22:28 -0400 Message-ID: <201005162322.o4GNMSaq007330@svn01.web.mwc.hst.phx2.redhat.com> --===============1048035609533463323== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Author: smumford Date: 2010-05-16 19:22:28 -0400 (Sun, 16 May 2010) New Revision: 3100 Modified: portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Referen= ce_Guide/en-US/Book_Info.xml portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Referen= ce_Guide/en-US/modules/Advanced/JCR/configuration.xml portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Referen= ce_Guide/en-US/modules/Advanced/JCR/intro.xml portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Referen= ce_Guide/en-US/modules/WSRP.xml Log: JBEPP-276: Edits in JCR section Modified: portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_= Reference_Guide/en-US/Book_Info.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/Book_Info.xml 2010-05-16 17:02:45 UTC (rev 3099) +++ portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/Book_Info.xml 2010-05-16 23:22:28 UTC (rev 3100) @@ -6,10 +6,10 @@ Reference Guide An in-depth guide to Enterprise Portal Platform 5.0 - &PRODUCT; - &VERSION; + JBoss Enterprise Portal Platform + 5.0 1 - 1.0 + 1.1 This Reference Guide is a high-level usage document. It deals with more= advanced topics than the Installation and User Guides, adding new content = or taking concepts discussed in the earlier documents further. It aims to p= rovide supporting documentation for advanced users of the &PRODUCT; product= . Its primary focus is on advanced use of the product and it assumes an int= ermediate or advanced knowledge of the technology and terms. Modified: portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_= Reference_Guide/en-US/modules/Advanced/JCR/configuration.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/modules/Advanced/JCR/configuration.xml 2010-05-16 17:02:45 = UTC (rev 3099) +++ portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/modules/Advanced/JCR/configuration.xml 2010-05-16 23:22:28 = UTC (rev 3100) @@ -9,7 +9,7 @@
Portal and Standalone configuration - Like other eXo services eXo JCR can be configured and used in portal or= embedded mode (as a service embedded in eXo Portal) and in standalone mode. + Like other eXo services eXo JCR can be configured and used in Portal (o= r Embedded) mode (as a service embedded in eXo Portal) and in Standalone mo= de. In Embedded mode, JCR services are registered in the Portal container. = In Standalone mode JCR uses a Standalone container. @@ -20,204 +20,342 @@ The following setup procedure is used to obtain a Standalone configurat= ion: + + - + + + Configuration must be explicitly set using StandaloneContain= er.addConfigurationURL(String url) or StandaloneContaine= r.addConfigurationPath(String path)before getInstance()<= /literal> makes a call. - + + + Configuration settings are read from $base:dir= ectory/exo-configuration.xml or $base:directory/conf/exo-configuration.xml. + + Replace $base:directory in the above locat= ions with, either the Application Server's home directory (in J2EE environm= ents) or the current directory for standalone applications. + - + + + The current classloader war or ear archive = must contain a /conf/exo-configuration.xml file. - + + + Further configuration setting are read from $s= ervice_jar_file/conf/portal/configuration.xml + + + Do not rely on the settings contained in any particular configuratio= n file if you have more than one jar archive that contains a <= filename>conf/portal/configuration.xml file. Behavior in this sc= enario can be erratic as the JCR's choice of configuration file is unpredic= table. + + = - JCR service configuration looks like: + The JCR service configuration is formatted as follows: + + + + + = -<component> - <key>org.exoplatform.services.jcr.RepositoryService</key> - <type>org.exoplatform.services.jcr.impl.RepositoryServiceImpl<= ;/type> - </component> - <component> - <key>org.exoplatform.services.jcr.config.RepositoryServiceConfig= uration</key> - <type>org.exoplatform.services.jcr.impl.config.RepositoryService= ConfigurationImpl</type> - <init-params> - <value-param> - <name>conf-path</name> - <description>JCR repositories configuration file</descrip= tion> - <value>jar:/conf/standalone/exo-jcr-config.xml</value> - </value-param> - <properties-param> - <name>working-conf</name> - <description>working-conf</description> - <property name=3D"source-name" value=3D"jdbcjcr" /> - <property name=3D"dialect" value=3D"hsqldb" /> - <property name=3D"persister-class-name" value=3D"org.exoplatfor= m.services.jcr.impl.config.JDBCConfigurationPersister" /> - </properties-param> - </init-params> - </component> - - - conf-path : a path to a RepositoryService JCR Configuration - - - working-conf : optional; JCR configuration persister configuration. If = there isn't a working-conf the persister will be disabled - + + org.exoplatform.services.jcr.RepositoryService + org.exoplatform.services.jcr.impl.RepositoryServiceImpl + + + org.exoplatform.services.jcr.config.RepositoryServiceConfiguratio= n + org.exoplatform.services.jcr.impl.config.RepositoryServiceConfig= urationImpl + + + + conf-path + JCR repositories configuration file + jar:/conf/standalone/exo-jcr-config.xml + + + = + working-conf + working-conf + + + + + + ]]> + + + + <conf-path> is a path to a Reposit= oryService JCR Configuration. + + + + + <working-conf> is an optional JCR configura= tion persister configuration. The persister will be disabled if there is no= <working-conf> defined. = + + + + +
JCR Configuration - The Configuration is defined in an XML file (see DTD below). + The JCR configuration is defined in an XML file (as per the DTD below). - JCR Service can use multiple Repositories and each repository can have= multiple Workspaces. + The JCR Service can use multiple Repositories and each repository can = have multiple Workspaces. - Repositories configuration parameters support human-readable formats o= f values. They are all case-insensitive: + The Repositories configuration parameters support human-readable forma= ts of values. They are not case-sensitive. - + + The parameters are: + + + + Number formats: - Numbers formats: K,KB - kilobytes, M,MB - megabytes, G,GB - gigabyte= s, T,TB - terabytes. + + + + K or = KB for kilobytes. + + + + + M or M= B for megabytes. + + + + + G or G= B for gigabytes. + + + + + T or T= B for terrabytes. + + + + + Examples: 200k or 200 Kbytes; 4m or 4 Mbytes; 1.4G or 1.4 Gbytes;= 10T or 10 Tbytes + + + - - Examples: 100.5 - digit 100.5, 200k - 200 Kbytes, 4m - 4 Mbytes, 1.4= G - 1.4 Gbytes, 10T - 10 Tbytes - + + + Time formats: - Time format endings: ms - milliseconds, s - seconds, m - minutes, h = - hours, d - days, w - weeks, if no ending - seconds. + + + + ms for milliseconds. + + + + + s for seconds. + + + + + m for minutes. + + + + + h for hours. + + + + + d for days. + + + + + w for weeks. + + + + + The default time format is seconds if no other format is specifie= d. + + + + + Examples: 500ms or 500 milliseconds; 20, 20s or 20 seconds; 30m o= r 30 minutes; 12h or 12 hours; 5d or 5 days; 4w or 4 weeks. + + + - - Examples: 500ms - 500 milliseconds, 20 or 20s - 20 seconds, 30m - 30= minutes, 12h - 12 hours, 5d - 5 days, 4w - 4 weeks. - - - - + +
=
Repository service configuration - Default configuration of the Repository Service located in jar:/conf/p= ortal/exo-jcr-config.xml, it will be available for portal and standalone mo= des. + The default configuration of the Repository Service is defined in jar:/conf/portal/exo-jcr-config.xml. It is available in both portal and standalone modes. - In portal mode it is overriden and located in the portal web applicati= on portal/WEB-INF/conf/jcr/repository-configuration.xml. + In portal mode it is overriden and located in the portal web applicati= on portal/WEB-INF/conf/jcr/repository-configuration.xml. - Example of Repository Service configuration for standalone mode: + An example of the Repository Service configuration for standalone mode= is included below: - = -<repository-service default-repository=3D"repository"&g= t; - <repositories> - <repository name=3D"db1" system-workspace=3D"ws" default-workspac= e=3D"ws"> - <security-domain>exo-domain</security-domain> - <access-control>optional</access-control> - <session-max-age>1h</session-max-age> - <authentication-policy>org.exoplatform.services.jcr.impl.co= re.access.JAASAuthenticator</authentication-policy> - <workspaces> - <workspace name=3D"production"> - <!-- for system storage --> - <container class=3D"org.exoplatform.services.jcr.impl.st= orage.jdbc.optimisation.CQJDBCWorkspaceDataContainer"> - <properties> - <property name=3D"source-name" value=3D"jdbcjcr" /= > - <property name=3D"multi-db" value=3D"false" /> - <property name=3D"update-storage" value=3D"false" = /> - <property name=3D"max-buffer-size" value=3D"200k" = /> - <property name=3D"swap-directory" value=3D"../temp= /swap/production" /> - </properties> - <value-storages> - <value-storage id=3D"system" class=3D"org.exoplatf= orm.services.jcr.impl.storage.value.fs.TreeFileValueStorage"> - <properties> - <property name=3D"path" value=3D"../temp/val= ues/production" /> - </properties> - <filters> - <filter property-type=3D"Binary" /> - </filters> - </value-storage> - </value-storages> - </container> - <initializer class=3D"org.exoplatform.services.jcr.impl.= core.ScratchWorkspaceInitializer"> - <properties> - <property name=3D"root-nodetype" value=3D"nt:unstr= uctured" /> - </properties> - </initializer> - <cache enabled=3D"true" class=3D"org.exoplatform.service= s.jcr.impl.dataflow.persistent.LinkedWorkspaceStorageCacheImpl"> - <properties> - <property name=3D"max-size" value=3D"10k" /> - <property name=3D"live-time" value=3D"1h" /> - </properties> - </cache> - <query-handler class=3D"org.exoplatform.services.jcr.imp= l.core.query.lucene.SearchIndex"> - <properties> - <property name=3D"index-dir" value=3D"../temp/jcrl= ucenedb/production" /> - </properties> - </query-handler> - <lock-manager> - <time-out>15m</time-out> - <persister class=3D"org.exoplatform.services.jcr.impl= .core.lock.FileSystemLockPersister"> - <properties> - <property name=3D"path" value=3D"../temp/lock/s= ystem" /> - </properties> - </persister> - </lock-manager> - </workspace> = - <workspace name=3D"backup"> - <container class=3D"org.exoplatform.services.jcr.impl.st= orage.jdbc.optimisation.CQJDBCWorkspaceDataContainer"> - <properties> - <property name=3D"source-name" value=3D"jdbcjcr" /= > - <property name=3D"multi-db" value=3D"false" /> - <property name=3D"update-storage" value=3D"false" = /> - <property name=3D"max-buffer-size" value=3D"200k" = /> - <property name=3D"swap-directory" value=3D"../temp= /swap/backup" /> - </properties> - <value-storages> - <value-storage id=3D"draft" class=3D"org.exoplatfo= rm.services.jcr.impl.storage.value.fs.TreeFileValueStorage"> - <properties> - <property name=3D"path" value=3D"../temp/val= ues/backup" /> - </properties> - <filters> - <filter property-type=3D"Binary" /> - </filters> - </value-storage> - </value-storages> - </container> - <initializer class=3D"org.exoplatform.services.jcr.impl.= core.ScratchWorkspaceInitializer"> - <properties> - <property name=3D"root-nodetype" value=3D"nt:unstr= uctured" /> - </properties> - </initializer> - <cache enabled=3D"true" class=3D"org.exoplatform.service= s.jcr.impl.dataflow.persistent.LinkedWorkspaceStorageCacheImpl"> - <properties> - <property name=3D"max-size" value=3D"10k" /> - <property name=3D"live-time" value=3D"1h" /> - </properties> - </cache> - <query-handler class=3D"org.exoplatform.services.jcr.imp= l.core.query.lucene.SearchIndex"> - <properties> - <property name=3D"index-dir" value=3D"../temp/jcrl= ucenedb/backup" /> - </properties> - </query-handler> - </workspace> - </workspaces> - </repository> - </repositories> -</repository-service> - + + = + + + + exo-domain + optional + 1h + org.exoplatform.services.jcr.impl.core.acc= ess.JAASAuthenticator + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 15m + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]]> + + + Repository Service configuration: @@ -248,11 +386,12 @@ + default-workspace - The name of a workspace obtained using Session's login() or login(Cre= dentials) methods (ones without an explicit workspace name). + = @@ -513,12 +652,12 @@ - = + + TODO LinkedWorkspaceStorageCacheImpl supports additional optional pa= rameters = + = = - = + = = Query Handler configuration: Modified: portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_= Reference_Guide/en-US/modules/Advanced/JCR/intro.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/modules/Advanced/JCR/intro.xml 2010-05-16 17:02:45 UTC (rev= 3099) +++ portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/modules/Advanced/JCR/intro.xml 2010-05-16 23:22:28 UTC (rev= 3100) @@ -6,7 +6,7 @@
Introduction - The Java Content Repository(JCR) API was created within the Java Commun= ity Process http://jcp.org/) as a collaboration between an expert group and the Java community. + The Java Content Repository (JCR) API was created within the Java Commu= nity Process http://jcp.org/) as a collaboration between an expert group and the Java community. Within the JCP, JCR is known as Java Specification Request-170 (JSR-170= ) ht= tp://www.jcp.org/en/jsr/detail?id=3D170. Modified: portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_= Reference_Guide/en-US/modules/WSRP.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/modules/WSRP.xml 2010-05-16 17:02:45 UTC (rev 3099) +++ portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/modules/WSRP.xml 2010-05-16 23:22:28 UTC (rev 3100) @@ -32,7 +32,7 @@ More information on WSRP can be found on the official website. - We suggest reading the primer for a comprehensive overview= of WSRP. + The primer is suggested reading for a comprehensive overvi= ew of WSRP.
= @@ -42,20 +42,20 @@ The WSRP Technical Committee defined WSRP Use Profiles to help with W= SRP interoperability. Terms defined in that document will be used in this s= ection. - &PRODUCT_NAME; provides a Simple level of support f= or our WSRP Producer except that out-of-band registration is not currently = handled. We support in-band registration and persistent local state (which = are defined at the Complex level). + &PRODUCT_NAME; provides a Simple level of support f= or our WSRP Producer except that out-of-band registration is not currently = handled. The WSRP component supports in-band registration and persistent lo= cal state (which are defined at the Complex level). - On the Consumer side, &PRODUCT_NAME; provides a Medium level of support for WSRP, except that we only handle HTML markup (as &= PRODUCT_NAME; itself doesn't handle other markup types). We do support expl= icit portlet cloning and we fully support the PortletManagement interface. + On the Consumer side, &PRODUCT_NAME; provides a Medium level of support for WSRP, except that it only handles HTML markup (as = &PRODUCT_NAME; itself doesn't handle other markup types). The WSRP componen= t does support explicit portlet cloning and the PortletManagement<= /literal> interface. - We has Level 1 Producer and Consumer caching. Cookie handling is support= ed properly on the Consumer and our Producer requires initialization of coo= kies (this improves interoperabilty with some consumers). + The WSRP component has Level 1 Producer and Consumer caching. Cookie han= dling is supported properly on the Consumer and our Producer requires initi= alization of cookies (this improves interoperabilty with some consumers). - We don't support custom window states or modes, as Portal doesn't either= . We do, however, support CSS on both the Producer (though it's more a func= tion of the portlets than inherent Producer capability) and Consumer. + The WSRP component does not support custom window states or modes, as Po= rtal doesn't either. The WSRP component does, however, support CSS on both= the Producer (though it is more a function of the portlets than an inheren= t Producer capability) and Consumer. - - While we provide a complete implementation of WSRP 1.0, we do need to go= through the Conformance statements and perform more interoperability te= sting (an area that needs to be better supported by the WSRP Technical Comm= ittee and Community at large). - + As of version &PRODUCT_VERSION; of &PRODUCT_NAME;, WSRP is only activat= ed and supported when &PRODUCT_NAME; is deployed on JBoss Application Serve= r. @@ -64,7 +64,7 @@ DOC TODO - Who or What is the WE referred to in= these paragraphs? Red Hat, &PRODUCT; or the developers of WSRP? + Replaced all references to we in thi= s file with either references to WSRP component or EPP. Does this break the= meaning?
@@ -247,50 +247,67 @@ - In the example above, the RemotelyExposedPortlet inhe= rits the remotable status defined at the portlet-app level sin= ce it does not specify a value for theorg.gatein.pc.remotable contain= er-runtime-option. TheNotRemotelyExposedPortlet, = however, overrides the default behavior and is not remotely exposed. Note t= hat in the absence of a top-level org.gatein.pc.remotable container-r= untime-option value set totrue, portlets are NOT remote= ly exposed. + In the example above, the RemotelyExposedPortlet inhe= rits the remotable status defined at the portlet-app level sin= ce it does not specify a value for theorg.gatein.pc.remotable contain= er-runtime-option. + + TheNotRemotelyExposedPortlet, however, overrides the = default behavior and is not remotely exposed. = + + + + Portlets are not remotely exposed if no top-level org.gatein.pc.r= emotable container-runtime-option value is set to true. + +
=
Consuming &PRODUCT_NAME;'s WSRP portlets from a remote Consumer</t= itle> <para> - WSRP Consumers vary a lot as far as how they are configured. Most of the= m require that you specify the URL for the Producer's WSDL definition. Plea= se refer to your Consumer's documentation for specific instructions. For in= structions on how to do so in &PRODUCT_NAME;, please refer to <xref linkend= =3D"sect-Reference_Guide-Web_Services_for_Remote_Portlets_WSRP-Consuming_re= mote_WSRP_portlets_in_PRODUCT_NAME" />. + Configuration is extremely variable between different WSRP Consumers. Mo= st, however, require a specification of the URL for the Producer's WSDL def= inition. </para> <para> - &PRODUCT_NAME;'s Producer is automatically set up when you deploy a port= al instance with the WSRP service. You can access the WSDL file at <filenam= e>http://{hostname}:{port}/wsrp-producer/MarkupService?wsdl</filename>. The= default hostname is <literal>localhost</literal> and the default port is 8= 080. + For instructions on how to specify this URL in &PRODUCT_NAME;, please re= fer to <xref linkend=3D"sect-Reference_Guide-Web_Services_for_Remote_Portle= ts_WSRP-Consuming_remote_WSRP_portlets_in_PRODUCT_NAME" />. </para> + <para> + &PRODUCT_NAME;'s Producer is automatically set up when a portal instance= is deployed with the WSRP service. + </para> + <para> + The WSDL file can be accessed at <filename>http://<replaceable>{hostname= }</replaceable>:<replaceable>{port}</replaceable>/wsrp-producer/MarkupServi= ce?wsdl</filename>. The default hostname is <literal>localhost</literal> an= d the default port is 8080. + </para> </section> = <section id=3D"sect-Reference_Guide-Web_Services_for_Remote_Portlets_WSRP= -Consuming_remote_WSRP_portlets_in_PRODUCT_NAME"> <title>Consuming remote WSRP portlets in &PRODUCT_NAME;
Overview - To be able to consume WSRP portlets exposed by a remote producer, &PRO= DUCT_NAME;'s WSRP consumer needs to know how to access that remote producer= . One can configure access to a remote producer using WSRP Producer descrip= tors. Alternatively, a portlet is provided to configure remote producers. + To be able to consume WSRP portlets exposed by a remote producer, &PRO= DUCT_NAME;'s WSRP consumer needs to know how to access that remote producer. + Access to a remote producer can be configured using WSRP Producer desc= riptors. Alternatively, a portlet is provided to configure remote producers. + + Once a remote producer has been configured, the portlets that it expos= es are then available in the Application Registry to be added to categories= and then to pages. - As a way to test the WSRP producer service and to check that the portl= ets that you want to expose remotely are correctly published via WSRP, a de= fault consumer named self, that consumes the portlets ex= posed by &PRODUCT_NAME;'s producer, has been configured. + A default consumer named self, that consumes the po= rtlets exposed by &PRODUCT_NAME;'s producer, has been configured as a way t= o test the WSRP producer service and to check that portlets are correctly p= ublished via WSRP.
= -
- Configuring a remote producer walk-through +
+ Configuring a remote producer - Let's work through the steps of defining access to a remote producer = so that its portlets can be consumed within &PRODUCT_NAME;. We will configu= re access to Oracle's public WSRP producer. We will first examine how to do= so using the configuration portlet. We will then show how the same result = can be accomplished with a producer descriptor, though it is far easier to = do so via the configuration portlet. + Let's work through the steps of defining access to a remote producer = so that its portlets can be consumed within &PRODUCT_NAME;. the WSRP compon= ent will configure access to Oracle's public WSRP producer. the WSRP compo= nent will first examine how to do so using the configuration portlet. the = WSRP component will then show how the same result can be accomplished with= a producer descriptor, though it is far easier to do so via the configurat= ion portlet. =
Using the configuration portlet - &PRODUCT_NAME; provides a portlet to configure access (among other = functions) to remote WSRP Producers grahically. It isn't, however, installe= d by default, so the first thing we will need to do is to install the WSRP = configuration portlet using the Application Registry. + &PRODUCT_NAME; provides a portlet to configure access (among other = functions) to remote WSRP Producers grahically. It isn't, however, installe= d by default, so the first thing the WSRP component will need to do is to = install the WSRP configuration portlet using the Application Registry. Use the usual procedure to log in as a Portal administrator and go = to the Application Registry. With the default install, you can just go to <= ulink url=3D"http://localhost:8080/portal/login?initialURI=3D%2Fportal%2Fpr= ivate%2Fclassic%2Fadministration%2Fregistry&username=3Droot&passwor= d=3Dgtn"> http://localhost:8080/portal/login?initialURI=3D%2Fportal%2Fpriva= te%2Fclassic%2Fadministration%2Fregistry&username=3Droot&password= =3Dgtn Add the WSRP Configuration portlet to the Administration ca= tegory. If you use the Import Applications functionality, the WSRP Configur= ation portlet will be automatically added to the Administration category. - Now that the portlet is added to a category, it can be added to a p= age and used. We recommend adding it to the same page as the Application Re= gistry as operations relating to WSRP and adding portlets to categories are= somewhat related as we will see. Go ahead and add the WSRP Configuration p= ortlet to the page using the standard procedure. + Now that the portlet is added to a category, it can be added to a p= age and used. the WSRP component recommend adding it to the same page as t= he Application Registry as operations relating to WSRP and adding portlets = to categories are somewhat related as the WSRP component will see. Go ahea= d and add the WSRP Configuration portlet to the page using the standard pro= cedure. If all went well, you should see something similar to this: @@ -304,7 +321,7 @@ This screen presents all the configured producers associated with = their status and possible actions on them. A Consumer can be active or inac= tive. Activating a Consumer means that it is ready to act as a portlet prov= ider. Note also that a Consumer can be marked as requiring refresh meaning = that the information held about it might not be up to date and refreshing i= t from the remote Producer might be a good idea. This can happen for severa= l reasons: the service description for that remote Producer has not been fe= tched yet, the cached version has expired or modifications have been made t= o the configuration that could potentially invalidate it, thus requiring re= -validation of the information. - Next, we create a new Consumer which we will calloracle. Type " oracle" in the "Create a consumer named:= " field then click on "Create consumer": + Next, the WSRP component create a new Consumer which the WSRP comp= onent will calloracle. Type " oracle= " in the "Create a consumer named:" field then click on "Create consumer": @@ -355,7 +372,7 @@
Using XML - While we recommend you use the WSRP Configuration portlet to confi= gure Consumers, we provide an alternative way to configure consumers by edi= ting the XML file located at $GATEIN_HOME/lib/wsrp-consumer-$WSRP= _VERSION.jar/conf/wsrp-consumers-config.xml. + While the WSRP component recommend you use the WSRP Configuration= portlet to configure Consumers, the WSRP component provide an alternative= way to configure consumers by editing the XML file located at $G= ATEIN_HOME/lib/wsrp-consumer-$WSRP_VERSION.jar/conf/wsrp-consumers-config.x= ml. = @@ -387,14 +404,14 @@ The file as shown above specifies access to two producers: self, which consumes &PRODUCT_NAME;'s own WSRP producer albeit = in a version that assumes that the producer requires a value for an email registration property, and oracle, whi= ch consumes Oracle's public producer, both in configurations as shown in th= e walk-through above. - We will look at the details of the meaning of elements later on. + the WSRP component will look at the details of the meaning of ele= ments later on.
=
Configuring access to a remote portlet - If we go back to the Application Registry and examine the availabl= e portlets by clicking on the Portlet link, you will now be able to see the= remote portlets if you click on the REMOTE tab in the left column: + If the WSRP component go back to the Application Registry and exa= mine the available portlets by clicking on the Portlet link, you will now b= e able to see the remote portlets if you click on the REMOTE tab in the lef= t column: @@ -418,7 +435,7 @@
Configuring access to remote producers via XML - While we recommend you use the WSRP Configuration portlet to configu= re Consumers, we provide an alternative way to configure consumers by editi= ng the XML file located at $GATEIN_HOME/lib/wsrp-consumer-$WSRP_V= ERSION.jar/conf/wsrp-consumers-config.xml. + While the WSRP component recommend you use the WSRP Configuration p= ortlet to configure Consumers, the WSRP component provide an alternative w= ay to configure consumers by editing the XML file located at $GAT= EIN_HOME/lib/wsrp-consumer-$WSRP_VERSION.jar/conf/wsrp-consumers-config.xml= . @@ -427,7 +444,7 @@ - It is important to note how the XML consumers configuration file is= processed. It is read the first time the WSRP service starts and the assoc= iated information is then put under control of JCR (Java Content Repository= ). Subsequent launches of the WSRP service will use the JCR-stored informat= ion for all producers are already known to &PRODUCT_NAME;. More specificall= y, wsrp-consumers-config.xml file is scanned for produ= cer identifiers. Any identifier that is already known will be bypassed and = the JCR information associated with this remote producer will be used. The = information defined at the XML level is only processed for producer definit= ion for which no information is already present in JCR. Therefore, if you w= ish to delete a producer configuration, you need to delete the associated i= nformation in the database (this can be accomplished using the configuratio= n portlet as we saw in ) AND= remove the associated information in wsrp-consumers-config.xml (if such information exists) as the producer will be re-created t= he next time the WSRP is launched if that information is not removed. + It is important to note how the XML consumers configuration file is= processed. It is read the first time the WSRP service starts and the assoc= iated information is then put under control of JCR (Java Content Repository= ). Subsequent launches of the WSRP service will use the JCR-stored informat= ion for all producers are already known to &PRODUCT_NAME;. More specificall= y, wsrp-consumers-config.xml file is scanned for produ= cer identifiers. Any identifier that is already known will be bypassed and = the JCR information associated with this remote producer will be used. The = information defined at the XML level is only processed for producer definit= ion for which no information is already present in JCR. Therefore, if you w= ish to delete a producer configuration, you need to delete the associated i= nformation in the database (this can be accomplished using the configuratio= n portlet as the WSRP component saw in ) AND remove the associated information in wsrp-consu= mers-config.xml (if such information exists) as the producer wil= l be re-created the next time the WSRP is launched if that information is n= ot removed. = @@ -437,7 +454,7 @@ Let's now look at which information needs to be provided to configu= re access to a remote producer. - First, we need to provide an identifier for the producer we are con= figuring so that we can refer to it afterwards. This is accomplished via th= e mandatory id attribute of the <wsrp-produc= er> element. + First, the WSRP component need to provide an identifier for the pr= oducer the WSRP component are configuring so that the WSRP component can = refer to it afterwards. This is accomplished via the mandatory id<= /literal> attribute of the <wsrp-producer> element. &PRODUCT_NAME; also needs to learn about the remote producer's endp= oints to be able to connect to the remote web services and perform WSRP inv= ocations. This is accomplished by specifying the URL for the WSDL descripti= on for the remote WSRP service, using the <endpoint-wsdl-url>= ; element. @@ -453,7 +470,7 @@ It is also possible to provide addtional configuration, which, in s= ome cases, might be important to establish a proper connection to the remot= e producer. - One such optional configuration concerns caching. To prevent useles= s roundtrips between the local consumer and the remote producer, it is poss= ible to cache some of the information sent by the producer (such as the lis= t of offered portlets) for a given duration. The rate at which the informat= ion is refreshed is defined by the expiration-cache attr= ibute of the <wsrp-producer> element which specifi= es the refreshing period in seconds. For example, providing a value of 120 = for expiration-cache means that the producer information will not be refres= hed for 2 minutes after it has been somehow accessed. If no value is provid= ed, &PRODUCT_NAME; will always access the remote producer regardless of whe= ther the remote information has changed or not. Since, in most instances, t= he information provided by the producer does not change often, we recommend= that you use this caching facility to minimize bandwidth usage. + One such optional configuration concerns caching. To prevent useles= s roundtrips between the local consumer and the remote producer, it is poss= ible to cache some of the information sent by the producer (such as the lis= t of offered portlets) for a given duration. The rate at which the informat= ion is refreshed is defined by the expiration-cache attr= ibute of the <wsrp-producer> element which specifi= es the refreshing period in seconds. For example, providing a value of 120 = for expiration-cache means that the producer information will not be refres= hed for 2 minutes after it has been somehow accessed. If no value is provid= ed, &PRODUCT_NAME; will always access the remote producer regardless of whe= ther the remote information has changed or not. Since, in most instances, t= he information provided by the producer does not change often, the WSRP com= ponent recommend that you use this caching facility to minimize bandwidth = usage. It is also possible to define a timeout after which WS operations a= re considered as failed. This is helpful to avoid blocking the WSRP service= , waiting forever on the service that doesn't answer. Use the ws-t= imeout attribute of the <wsrp-producer> = element to specify how many milliseconds the WSRP service will wait for a r= esponse from the remote producer before timing out and giving up. @@ -537,10 +554,10 @@ There might also be cases where you just want to update the regist= ration information because it has changed. For example, the producer requir= ed you to provide a valid email and the previously email address is not val= id anymore and needs to be updated. - It is therefore sometimes necessary to modify the registration tha= t concretizes the service agreement between a consumer and a producer. Let'= s take the example of the producer requiring an email we configured in . If you recall, the producer was requ= iring registration and required a value to be provided for the ema= il property. + It is therefore sometimes necessary to modify the registration tha= t concretizes the service agreement between a consumer and a producer. Let'= s take the example of the producer requiring an email the WSRP component c= onfigured in . If you recall, the = producer was requiring registration and required a value to be provided for= the email property. - Suppose now that we would like to update the email address that we= provided to the remote producer. We will need to tell the producer that ou= r registration data has been modified. Let's see how to do this. Assuming y= ou have configured access to the producer as previously described, please g= o to the configuration screen for the self producer and = modify the value of email to foo(a)example.com<= /literal> instead ofexample(a)example.com: = + Suppose now that the WSRP component would like to update the emai= l address that the WSRP component provided to the remote producer. the WSR= P component will need to tell the producer that our registration data has = been modified. Let's see how to do this. Assuming you have configured acces= s to the producer as previously described, please go to the configuration s= creen for the self producer and modify the value of email to foo(a)example.com instead ofexample(a)example.com: = @@ -568,7 +585,7 @@
Registration modification on producer error - It can also happen that a producer administrator decided to change= its requirement forregistered consumers. In this case, invoking operations= on the producer will fail with an OperationFailedFault. &PRODUCT_NAME; will attempt to help you in this situation. Let= 's walk through an example using the self producer. Let'= s assume that registration is requiring a valid value for an email= registration property (as we have seen so far). If you go to the= configuration screen for this producer, you should see: = + It can also happen that a producer administrator decided to change= its requirement forregistered consumers. In this case, invoking operations= on the producer will fail with an OperationFailedFault. &PRODUCT_NAME; will attempt to help you in this situation. Let= 's walk through an example using the self producer. Let'= s assume that registration is requiring a valid value for an email= registration property (as the WSRP component have seen so far).= If you go to the configuration screen for this producer, you should see: = @@ -576,7 +593,7 @@ - Now suppose that the administrator of the producer now additional= y requires a value to be provided for a name registratio= n property. We will actually see how to do perform this operation in &PRODU= CT_NAME; when we examine how to configure &PRODUCT_NAME;'s producer in . Operations with this producer wil= l now fail. If you suspect that a registration modification is required, yo= u should go to the configuration screen for this remote producer and refres= h the information held by the consumer by pressing "Refresh & Save": = + Now suppose that the administrator of the producer now additional= y requires a value to be provided for a name registratio= n property. the WSRP component will actually see how to do perform this op= eration in &PRODUCT_NAME; when the WSRP component examine how to configure= &PRODUCT_NAME;'s producer in .= Operations with this producer will now fail. If you suspect that a registr= ation modification is required, you should go to the configuration screen f= or this remote producer and refresh the information held by the consumer by= pressing "Refresh & Save": = @@ -679,7 +696,7 @@
Default configuration - The default producer configuration is to require that consumers reg= ister with it before providing access its services but does not require any= specific registration properties (apart from what is mandated by the WSRP = standard). It does, however, require consumers to be registered before send= ing them a full service description. This means that our WSRP producer will= not provide the list of offered portlets and other capabilities to unregis= tered consumers. The producer also uses the default Registration= Policy paired with the default RegistrationPropertyV= alidator. We will look into property validators in greater deta= il later in. Suffice to say for now that t= his allows users to customize how Portal's WSRP Producer decides whether a = given registration property is valid or not. + The default producer configuration is to require that consumers reg= ister with it before providing access its services but does not require any= specific registration properties (apart from what is mandated by the WSRP = standard). It does, however, require consumers to be registered before send= ing them a full service description. This means that our WSRP producer will= not provide the list of offered portlets and other capabilities to unregis= tered consumers. The producer also uses the default Registration= Policy paired with the default RegistrationPropertyV= alidator. the WSRP component will look into property validator= s in greater detail later in. Suffice to s= ay for now that this allows users to customize how Portal's WSRP Producer d= ecides whether a given registration property is valid or not. &PRODUCT_NAME; provides a web interface to configure the producer's= behavior. You can access it by clicking on the "Producer Configuration" ta= b of the "WSRP" page of the "admin" portal. Here's what you should see with= the default configuration: = @@ -705,7 +722,7 @@ - We will allow unregistered consumers to see the list of offered po= rtlets so we leave the first checkbox ("Access to full service description = requires consumers to be registered.") unchecked. We will, however, specify= that consumers will need to be registered to be able to interact with our = producer. Check the second checkbox ("Requires registration. Modifying this= information will trigger invalidation of consumer registrations."). The sc= reen should now refresh and display: = + the WSRP component will allow unregistered consumers to see the l= ist of offered portlets so the WSRP component leave the first checkbox ("A= ccess to full service description requires consumers to be registered.") un= checked. the WSRP component will, however, specify that consumers will nee= d to be registered to be able to interact with our producer. Check the seco= nd checkbox ("Requires registration. Modifying this information will trigge= r invalidation of consumer registrations."). The screen should now refresh = and display: = @@ -713,7 +730,7 @@ - You can specify the fully-qualified name for your Regis= trationPolicy and RegistrationPropertyValidator there. We will keep the default value. See for more details. Let's add, however, a registration prop= erty called email. Click "Add property" and enter the ap= propriate information in the fields, providing a description for the regist= ration property that can be used by consumers to figure out its purpose: + You can specify the fully-qualified name for your Regis= trationPolicy and RegistrationPropertyValidator there. the WSRP component will keep the default value. See for more details. Let's add, however, a = registration property called email. Click "Add property"= and enter the appropriate information in the fields, providing a descripti= on for the registration property that can be used by consumers to figure ou= t its purpose: = @@ -730,7 +747,7 @@ - If consumers are already registered with the producer, modifying t= he configuration of required registration information will trigger the inva= lidation of held registrations, requiring consumers to modify their registr= ation before being able to access the producer again. We saw the consumer s= ide of that process in . + If consumers are already registered with the producer, modifying t= he configuration of required registration information will trigger the inva= lidation of held registrations, requiring consumers to modify their registr= ation before being able to access the producer again. the WSRP component s= aw the consumer side of that process in .
@@ -745,7 +762,7 @@ Please refer to the Javadoc for org.jboss.portal.registration.RegistrationPolicy and org.jboss.portal.Registration.policies.RegistrationPrope= rtyValidator for more details on what is expected of each metho= d. - Defining a registration policy is required for the producer to b= e correctly configured. This is accomplished by specifying the qualified cl= ass name of the registration policy. Since we anticipate that most users wi= ll use the default registration policy, it is possible to provide the class= name of your custom property validator instead to customize the default re= gistration policy behavior. Note that property validators are only used by = the default policy. = + Defining a registration policy is required for the producer to b= e correctly configured. This is accomplished by specifying the qualified cl= ass name of the registration policy. Since the WSRP component anticipate t= hat most users will use the default registration policy, it is possible to = provide the class name of your custom property validator instead to customi= ze the default registration policy behavior. Note that property validators = are only used by the default policy. = @@ -758,7 +775,7 @@
WSRP validation mode - The lack of conformance kit and the wording of the WSRP specificat= ion leaves room for differing interpretations, resulting in interoperabilit= y issues. It is therefore possible to encounter issues when using consumers= from different vendors. We have experienced such issues and have introduce= d a way to relax the validation that our WSRP producer performs on the data= provided by consumers to help with interoperability by accepting data that= would normally be invalid. Note that we only relax our validation algorith= m on aspects of the specification that are deemed harmless such as invalid = language codes. + The lack of conformance kit and the wording of the WSRP specificat= ion leaves room for differing interpretations, resulting in interoperabilit= y issues. It is therefore possible to encounter issues when using consumers= from different vendors. the WSRP component have experienced such issues a= nd have introduced a way to relax the validation that our WSRP producer per= forms on the data provided by consumers to help with interoperability by ac= cepting data that would normally be invalid. Note that the WSRP component = only relax our validation algorithm on aspects of the specification that ar= e deemed harmless such as invalid language codes. By default, the WSRP producer is configured in strict mode. If you= experience issues with a given consumer, you might want to try to relax th= e validation mode. This is accomplished by unchecking the "Use strict WSRP = compliance." checkbox on the Producer configuration screen. --===============1048035609533463323==--