[gatein-commits] gatein SVN: r8289 - in epp/docs/branches/5.2/Reference_Guide/en-US: modules/AuthenticationAndIdentity and 3 other directories.

Author: smumford Date: 2012-01-09 18:43:14 -0500 (Mon, 09 Jan 2012) New Revision: 8289 Modified: epp/docs/branches/5.2/Reference_Guide/en-US/Book_Info.xml epp/docs/branches/5.2/Reference_Guide/en-US/Revision_History.xml epp/docs/branches/5.2/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/XMLResourceBundles.xml epp/docs/branches/5.2/Reference_Guide/en-US/modules/eXoJCR/faq/jcr-faq.xml epp/docs/branches/5.2/Reference_Guide/en-US/modules/eXoJCR/ws/groovy-scripts-as-rest-services.xml Log: Version increment and spellcheck edit Modified: epp/docs/branches/5.2/Reference_Guide/en-US/Book_Info.xml =================================================================== --- epp/docs/branches/5.2/Reference_Guide/en-US/Book_Info.xml 2012-01-09 20:09:39 UTC (rev 8288) +++ epp/docs/branches/5.2/Reference_Guide/en-US/Book_Info.xml 2012-01-09 23:43:14 UTC (rev 8289) @@ -5,11 +5,11 @@ ]> <bookinfo id="book-Reference_Guide-Reference_Guide"> <title>Reference Guide</title> - <subtitle>An in-depth guide to Enterprise Portal Platform &VZ;</subtitle> + <subtitle>An in-depth guide to Enterprise Portal Platform 5.2.0</subtitle> <productname>JBoss Enterprise Portal Platform</productname> <productnumber>5.2</productnumber> - <edition>5.2.0</edition> - <pubsnumber>100</pubsnumber> + <edition>5.2.1</edition> + <pubsnumber>5</pubsnumber> <abstract> <para> 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 provide supporting documentation for advanced users of the JBoss Enterprise Portal Platform product. Its primary focus is on advanced use of the product and it assumes an intermediate or advanced knowledge of the technology and terms. Modified: epp/docs/branches/5.2/Reference_Guide/en-US/Revision_History.xml =================================================================== --- epp/docs/branches/5.2/Reference_Guide/en-US/Revision_History.xml 2012-01-09 20:09:39 UTC (rev 8288) +++ epp/docs/branches/5.2/Reference_Guide/en-US/Revision_History.xml 2012-01-09 23:43:14 UTC (rev 8289) @@ -8,6 +8,20 @@ <simpara> <revhistory> <revision> + <revnumber>5.2.1-5</revnumber> + <date>Mon Jan 09 2012</date> + <author> + <firstname>Scott</firstname> + <surname>Mumford</surname> + <email></email> + </author> + <revdescription> + <simplelist> + <member>Added new content to Authentication and Identity.</member> + </simplelist> + </revdescription> + </revision> + <revision> <revnumber>5.2.0-100</revnumber> <date>Wed Dec 14 2011</date> <author> Modified: epp/docs/branches/5.2/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml =================================================================== --- epp/docs/branches/5.2/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml 2012-01-09 20:09:39 UTC (rev 8288) +++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml 2012-01-09 23:43:14 UTC (rev 8289) @@ -79,7 +79,7 @@ This means that access to some URLs (such as <ulink type="http" url="http://localhost:8080/portal/dologin">http://localhost:8080/portal/dologin</ulink>) will directly trigger J2EE authentication in the case that the user is not already logged in. </para> <para> - Access to this URL also means that the user needs to be in the JAAS group <emphasis>users</emphasis>, otherwise they can authenticate but will recieve an HTTP error; <emphasis>403 Forbidden</emphasis>, for example. + Access to this URL also means that the user needs to be in the JAAS group <emphasis>users</emphasis>, otherwise they can authenticate but will receive an HTTP error; <emphasis>403 Forbidden</emphasis>, for example. </para> <para> @@ -236,7 +236,7 @@ <term>PortalLoginModule</term> <listitem> <para> - This login module is actually used mainly in cluster environments. It uses session replication between cluster nodes. After a successful authentication on cluster <emphasis>node1</emphasis> the <emphasis>commit</emphasis> method adds a flag (with the attribute <emphasis>AUTHENTICATED_CREDENTIALS</emphasis>) to the HTTP session and this flag can then be used to reauthenticate on <emphasis>node2</emphasis> when it executes method <emphasis>login</emphasis>. Refer to <xref linkend="sect-Authentication_Authorization_Intro-ClusterLogin" /> for more information. + This login module is actually used mainly in cluster environments. It uses session replication between cluster nodes. After a successful authentication on cluster <emphasis>node1</emphasis> the <emphasis>commit</emphasis> method adds a flag (with the attribute <emphasis>AUTHENTICATED_CREDENTIALS</emphasis>) to the HTTP session and this flag can then be used to re-authenticate on <emphasis>node2</emphasis> when it executes method <emphasis>login</emphasis>. Refer to <xref linkend="sect-Authentication_Authorization_Intro-ClusterLogin" /> for more information. </para> </listitem> </varlistentry> @@ -339,7 +339,7 @@ <title>Authentication on application server level</title> <para> - Application server needs to properly recognize that user is successfuly logged and it has assigned his JAAS roles. Unfortunately this part is not standardized and is specific for each AS. For example in JBoss AS, you need to ensure that JAAS Subject has assigned principal with username (UserPrincipal) and also RolesPrincipal, which has name "Roles" and it contains list of JAAS roles. This part is actually done in <code>JbossLoginModule.commit()</code>. In Tomcat, this flow is little different, which means Tomcat has it is own <literal>TomcatLoginModule</literal>. + Application server needs to properly recognize that user is successfully logged and it has assigned his JAAS roles. Unfortunately this part is not standardized and is specific for each AS. For example in JBoss AS, you need to ensure that JAAS Subject has assigned principal with username (UserPrincipal) and also RolesPrincipal, which has name "Roles" and it contains list of JAAS roles. This part is actually done in <code>JbossLoginModule.commit()</code>. In Tomcat, this flow is little different, which means Tomcat has it is own <literal>TomcatLoginModule</literal>. </para> </formalpara> @@ -395,7 +395,7 @@ </para> <para> - Method <emphasis>createIdentity</emphasis> is used to create instance of object <emphasis>org.exoplatform.services.security.Identity</emphasis>, which encapsulates all important informations about single user like: + Method <emphasis>createIdentity</emphasis> is used to create instance of object <emphasis>org.exoplatform.services.security.Identity</emphasis>, which encapsulates all important information about single user like: </para> <itemizedlist> @@ -407,7 +407,7 @@ <listitem> <para> - set of Memberships (MembershipEntry objects) which user belongs to. <emphasis>Membership</emphasis> is object, which contains informations about <emphasis>membershipType</emphasis> (manager, member, validator, ... ) and about <emphasis>group</emphasis> (/platform/users, /platform/administrators, /partners, /organization/management/executiveBoard, ... ). + set of Memberships (MembershipEntry objects) which user belongs to. <emphasis>Membership</emphasis> is object, which contains information about <emphasis>membershipType</emphasis> (manager, member, validator, ... ) and about <emphasis>group</emphasis> (/platform/users, /platform/administrators, /partners, /organization/management/executiveBoard, ... ). </para> </listitem> @@ -434,7 +434,7 @@ ]]> </programlisting> <para> - Default implementation <emphasis>DefaultRolesExtractorImpl</emphasis> is based on special algorithm, which uses name of role from the root of the group (for example for role "/organization/management/something" we have JAAS role "organization"). Only exception is group "platform" where we use 2nd level as name of group. For example from group "/platform/users" we have JAAS role "users". + Default implementation <emphasis>DefaultRolesExtractorImpl</emphasis> is based on special algorithm, which uses name of role from the root of the group (for example for role "/organization/management/something" we have JAAS role "organization"). Only exception is group "platform" where we use second level as name of group. For example from group "/platform/users" we have JAAS role "users". </para> <para> @@ -446,7 +446,7 @@ </para> <para> - You can override default implementation of mentioned interfaces Authenticator and RolesExtractor if default behaviour is not suitable for your needs. Consult documentation of <emphasis>eXo kernel</emphasis> for more info. + You can override default implementation of mentioned interfaces Authenticator and RolesExtractor if default behavior is not suitable for your needs. Consult documentation of <emphasis>eXo kernel</emphasis> for more info. </para> </section> <!-- Ending section Authenticator and RolesExtractor --> @@ -459,7 +459,7 @@ <title>RememberMe authentication</title> <para> - In default login dialog, you can notice that there is "Remember my login" checkbox, which users can use to persist their login on his workstation. Default validity period of RememberMe cookie is one day (it is configurable), and so user can be logged for whole day before he need to reauthenticate again with his credentials. + In default login dialog, you can notice that there is "Remember my login" checkbox, which users can use to persist their login on his workstation. Default validity period of RememberMe cookie is one day (it is configurable), and so user can be logged for whole day before he need to re-authenticate again with his credentials. </para> <section id="sect-Authentication_Authorization_Intro-RememberMeAuthentication-howDoesItWork"> @@ -480,7 +480,7 @@ <listitem> <para> - Request is processed by PortalLoginController servlet. Servlet obtains instance of <emphasis>RemindPasswordTokenService</emphasis> and save user credentials into JCR. It generates and returns special token (key) for later use. Then it creates cookie called <emphasis>rememberme</emphasis> and use returned token as value of cookie. + Request is processed by PortalLoginController servlet. Servlet obtains instance of <emphasis>RemindPasswordTokenService</emphasis> and save user credentials into JCR. It generates and returns special token (key) for later use. Then it creates cookie called <emphasis>RememberMe</emphasis> and use returned token as value of cookie. </para> </listitem> </itemizedlist> @@ -492,19 +492,19 @@ <itemizedlist> <listitem> <para> - After some time, user wants to reauthenticate. Let's assume that his HTTP Session is already expired but his RememberMe cookie is still active. + After some time, user wants to re-authenticate. Let's assume that his HTTP Session is already expired but his RememberMe cookie is still active. </para> </listitem> <listitem> <para> - User send HTTP request to some portal page (ie. <filename>http://localhost:8080/portal/classic</filename> ). + User send HTTP request to some portal page (<filename>http://localhost:8080/portal/classic</filename> ). </para> </listitem> <listitem> <para> - There is special HTTP Filter <emphasis role="bold">RememberMeFilter</emphasis> configured in web.xml, which checks rememberme cookie and then it retrieves credentials of user from RemindPasswordTokenService. Now filter redirects request to PortalLoginController and authentication process goes in same way as for normal FORM based authentication. + There is special HTTP Filter <emphasis role="bold">RememberMeFilter</emphasis> configured in web.xml, which checks RememberMe cookie and then it retrieves credentials of user from RemindPasswordTokenService. Now filter redirects request to PortalLoginController and authentication process goes in same way as for normal FORM based authentication. </para> </listitem> </itemizedlist> @@ -548,7 +548,7 @@ ]]> </programlisting> <para> - In this case user will see login dialog from browser instead of JBoss Enterprise Portal Platform login.jsp page. JAAS authentication will be performed with real credentials of user (ie. <emphasis>root</emphasis>/<emphasis>gtn</emphasis>). WCI ticket is not used with BASIC authentication. + In this case user will see login dialog from browser instead of JBoss Enterprise Portal Platform login.jsp page. JAAS authentication will be performed with real credentials of user (<emphasis>root</emphasis>/<emphasis>gtn</emphasis>). WCI ticket is not used with BASIC authentication. </para> </section> @@ -615,7 +615,7 @@ </para> <para> - In other words, you need to ensure that users, which are logged successfuly through SSO, needs to be also in JBoss Enterprise Portal Platform identity database because SSO server is used only for authentication, but authorization is handled completely by JBoss Enterprise Portal Platform, which assumes that user exists in portal DB. If users are not in DB, Identity object won't be created and you will have 403 Forbidden errors even if you authenticate successfuly. For details about SSO integration, see <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On" />. + In other words, you need to ensure that users, which are logged successfully through SSO, needs to be also in JBoss Enterprise Portal Platform identity database because SSO server is used only for authentication, but authorization is handled completely by JBoss Enterprise Portal Platform, which assumes that user exists in portal DB. If users are not in DB, Identity object won't be created and you will have 403 Forbidden errors even if you authenticate successfully. For details about SSO integration, see <xref linkend="sect-Reference_Guide-SSO_Single_Sign_On" />. </para> <para> @@ -660,11 +660,11 @@ <role-name>users</role-name> </auth-constraint>]]></programlisting> <para> - This actually means that our user needs to be in JBoss Enterprise Portal Platform role <emphasis>/platform/users</emphasis> (For details see <xref linkend="sect-Authentication_Authorization_Intro-authenticatorAndRolesExtractor" />). In other words, if we successfuly authenticate but our user is not in group <emphasis>/platform/users</emphasis>, then it means that he is not in JAAS role <emphasis>users</emphasis>, which in next turn means that he will have authorization error <emphasis role="bold">403 Forbidden</emphasis> thrown by servlet container. + This actually means that our user needs to be in JBoss Enterprise Portal Platform role <emphasis>/platform/users</emphasis> (For details see <xref linkend="sect-Authentication_Authorization_Intro-authenticatorAndRolesExtractor" />). In other words, if we successfully authenticate but our user is not in group <emphasis>/platform/users</emphasis>, then it means that he is not in JAAS role <emphasis>users</emphasis>, which in next turn means that he will have authorization error <emphasis role="bold">403 Forbidden</emphasis> thrown by servlet container. </para> <para> - You can change the behaviour and possibly add some more <emphasis>auth-constraint</emphasis> elements into <filename>web.xml</filename>. However this protection of resources based on web.xml is not standard JBoss Enterprise Portal Platform way and it is mentioned here mainly for illustration purposes. + You can change the behavior and possibly add some more <emphasis>auth-constraint</emphasis> elements into <filename>web.xml</filename>. However this protection of resources based on web.xml is not standard JBoss Enterprise Portal Platform way and it is mentioned here mainly for illustration purposes. </para> </section> @@ -672,7 +672,7 @@ <title>Portal level authorization</title> <para> - Second round of authorization is based on component <emphasis role="bold">UserACL</emphasis> (See <xref linkend="chap-Reference_Guide-Portal_Default_Permission_Configuration" />). We can declare access and edit permissions for portals, pages and/or portlets. UserACL is then used to check if our user has particular permissions to access or edit specified resource. Important object with informations about roles of our user is mentioned <emphasis>Identity</emphasis> object created during JAAS authentication. + Second round of authorization is based on component <emphasis role="bold">UserACL</emphasis> (See <xref linkend="chap-Reference_Guide-Portal_Default_Permission_Configuration" />). We can declare access and edit permissions for portals, pages and/or portlets. UserACL is then used to check if our user has particular permissions to access or edit specified resource. Important object with information about roles of our user is mentioned <emphasis>Identity</emphasis> object created during JAAS authentication. </para> <para> Modified: epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/XMLResourceBundles.xml =================================================================== --- epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/XMLResourceBundles.xml 2012-01-09 20:09:39 UTC (rev 8288) +++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/PortalDevelopment/XMLResourceBundles.xml 2012-01-09 23:43:14 UTC (rev 8289) @@ -13,7 +13,7 @@ <itemizedlist> <listitem> <para> - The XML format declares the encoding of the file. This avoids use of the <literal>native2ascii</literal> program which can interfere with encoding. + The XML format declares the encoding of the file. This avoids use of the <literal>native2ASCII</literal> program which can interfere with encoding. </para> </listitem> Modified: epp/docs/branches/5.2/Reference_Guide/en-US/modules/eXoJCR/faq/jcr-faq.xml =================================================================== --- epp/docs/branches/5.2/Reference_Guide/en-US/modules/eXoJCR/faq/jcr-faq.xml 2012-01-09 20:09:39 UTC (rev 8288) +++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/eXoJCR/faq/jcr-faq.xml 2012-01-09 23:43:14 UTC (rev 8289) @@ -70,7 +70,7 @@ JCR Observation's a way to listen on persistence changes of a Repository. It provides several options to configure the listener for an interesting only changes. To use properly, it's important to understand concept of events filtering for a registered EventListener. </para> <para> - An often confusing part is the <emphasis role="bold">absPath</emphasis>, it is an associated parent of a location you want to observe events on. That is to say it is a parent of child node(s) or this parent property(ies); if <emphasis role="bold">isDeep</emphasis> is true then you'll get events of all the subtree of child nodes also. The same actual for <emphasis role="bold">uuid</emphasis> and <emphasis role="bold">nodeTypeName</emphasis> parameters of ObservationManager.addEventListener() method. + An often confusing part is the <emphasis role="bold">absPath</emphasis>, it is an associated parent of a location you want to observe events on. That is to say it is a parent of child node(s) or this parent properties; if <emphasis role="bold">isDeep</emphasis> is true then you'll get events of all the subtree of child nodes also. The same actual for <emphasis role="bold">uuid</emphasis> and <emphasis role="bold">nodeTypeName</emphasis> parameters of ObservationManager.addEventListener() method. </para> </listitem> Modified: epp/docs/branches/5.2/Reference_Guide/en-US/modules/eXoJCR/ws/groovy-scripts-as-rest-services.xml =================================================================== --- epp/docs/branches/5.2/Reference_Guide/en-US/modules/eXoJCR/ws/groovy-scripts-as-rest-services.xml 2012-01-09 20:09:39 UTC (rev 8288) +++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/eXoJCR/ws/groovy-scripts-as-rest-services.xml 2012-01-09 23:43:14 UTC (rev 8289) @@ -4,63 +4,63 @@ %BOOK_ENTITIES; ]> <chapter id="chap-Reference_Guide-Groovy_Scripts_as_REST_Services"> - <title>Groovy Scripts as REST Services</title> - <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Overview"> - <title>Overview</title> - <para> - This article describes how to use Groovy scripts as REST services. We are going to consider these operations: - </para> - <itemizedlist> - <listitem> - <para> - Load script and save it in JCR. - </para> + <title>Groovy Scripts as REST Services</title> + <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Overview"> + <title>Overview</title> + <para> + This article describes how to use Groovy scripts as REST services. We are going to consider these operations: + </para> + <itemizedlist> + <listitem> + <para> + Load script and save it in JCR. + </para> - </listitem> - <listitem> - <para> - Instantiate script - </para> + </listitem> + <listitem> + <para> + Instantiate script + </para> - </listitem> - <listitem> - <para> - Deploy newly created Class as RESTful service. - </para> + </listitem> + <listitem> + <para> + Deploy newly created Class as RESTful service. + </para> - </listitem> - <listitem> - <para> - Script Lifecycle Management. - </para> + </listitem> + <listitem> + <para> + Script Lifecycle Management. + </para> - </listitem> - <listitem> - <para> - And finally we will discover simple example which can get JCR node UUID - </para> + </listitem> + <listitem> + <para> + And finally we will discover simple example which can get JCR node UUID + </para> - </listitem> + </listitem> - </itemizedlist> - <para> - In this article, we consider RESTful service compatible with JSR-311 specification. Currently last feature available in version 1.11-SNAPSHOT of JCR, 2.0-SNAPSHOT of WS and version 2.1.4-SNAPSHOT of core. - </para> + </itemizedlist> + <para> + In this article, we consider RESTful service compatible with JSR-311 specification. Currently last feature available in version 1.11-SNAPSHOT of JCR, 2.0-SNAPSHOT of WS and version 2.1.4-SNAPSHOT of core. + </para> - </section> - - <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Loading_script_and_save_it_in_JCR"> - <title>Loading script and save it in JCR</title> - <para> - There are two ways to save a script in JCR. The first way is to save it at server startup time by using configuration.xml and the second way is to upload the script via HTTP. - </para> - <para> - <command>Load script at startup time</command> - </para> - <para> - This way can be used for load prepared scripts, to use this way. we must configure org.exoplatform.services.jcr.ext.script.groovy.GroovyScript2RestLoaderPlugin. This is simple configuration example. - </para> - + </section> + + <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Loading_script_and_save_it_in_JCR"> + <title>Loading script and save it in JCR</title> + <para> + There are two ways to save a script in JCR. The first way is to save it at server startup time by using configuration.xml and the second way is to upload the script via HTTP. + </para> + <para> + <command>Load script at startup time</command> + </para> + <para> + This way can be used for load prepared scripts, to use this way. we must configure org.exoplatform.services.jcr.ext.script.groovy.GroovyScript2RestLoaderPlugin. This is simple configuration example. + </para> + <programlisting language="XML" role="XML">&lt;external-component-plugins&gt; &lt;target-component&gt;org.exoplatform.services.jcr.ext.script.groovy.GroovyScript2RestLoader&lt;/target-component&gt; &lt;component-plugin&gt; @@ -88,54 +88,54 @@ &lt;/init-params&gt; &lt;/component-plugin&gt; &lt;/external-component-plugins&gt;</programlisting> - <para> - The first is value-param sets JCR repository, the second is value-param sets workspace and the third one is sets JCR node where scripts from plugin will be stored. If specified node does not exist, then it will be created. List of scripts is set by properties-params. Name of each properties-param will be used as node name for stored script, property autoload says to deploy this script at startup time, property path sets the source of script to be loaded. In this example we try to load single script from local file /home/andrew/JcrGroovyTest.groovy. - </para> - <para> - <command>Load script via HTTP</command> - </para> - <para> - This is samples of HTTP requests. In this example, we will upload script from file with name test.groovy. - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + <para> + The first is value-param sets JCR repository, the second is value-param sets workspace and the third one is sets JCR node where scripts from plugin will be stored. If specified node does not exist, then it will be created. List of scripts is set by properties-params. Name of each properties-param will be used as node name for stored script, property autoload says to deploy this script at startup time, property path sets the source of script to be loaded. In this example we try to load single script from local file /home/andrew/JcrGroovyTest.groovy. + </para> + <para> + <command>Load script via HTTP</command> + </para> + <para> + This is samples of HTTP requests. In this example, we will upload script from file with name test.groovy. + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ -X POST \ -H 'Content-type:script/groovy' \ --data-binary @test.groovy \ http://localhost:8080/rest/script/groovy/add/repository/production/script... - <para> - This example imitate sending data with HTML form ('multipart/form-data'). Parameter autoload is optional. If parameter autoload=true then script will be instantiate and deploy script immediately. - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + <para> + This example imitate sending data with HTML form ('multipart/form-data'). Parameter autoload is optional. If parameter autoload=true then script will be instantiate and deploy script immediately. + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ -X POST \ -F &quot;file=(a)test.groovy;name=test&quot; \ -F "autoload=true" \ http://localhost:8080/rest/script/groovy/add/repository/production/script... - </section> - - <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Instantiation"> - <title>Instantiation</title> - <para> - org.exoplatform.services.script.groovy.GroovyScriptInstantiator is part of project exo.core.component.script.groovy. GroovyScriptInstantiator can load script from specified URL and parse stream that contains Groovy source code. It has possibility inject component from Container in Groovy Class constructor. Configuration example: - </para> - + </section> + + <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Instantiation"> + <title>Instantiation</title> + <para> + org.exoplatform.services.script.groovy.GroovyScriptInstantiator is part of project exo.core.component.script.groovy. GroovyScriptInstantiator can load script from specified URL and parse stream that contains Groovy source code. It has possibility inject component from Container in Groovy Class constructor. Configuration example: + </para> + <programlisting language="XML" role="XML">&lt;component&gt; &lt;type&gt;org.exoplatform.services.script.groovy.GroovyScriptInstantiator&lt;/type&gt; &lt;/component&gt;</programlisting> - </section> - - <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Deploying_newly_created_Class_as_RESTful_service"> - <title>Deploying newly created Class as RESTful service</title> - <para> - To deploy script automatically at server startup time, its property exo:autoload must be set as true. org.exoplatform.services.jcr.ext.script.groovy.GroovyScript2RestLoader check JCR workspaces which were specified in configuration and deploy all auto-loadable scripts. - </para> - <para> - Example of configuration. - </para> - + </section> + + <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Deploying_newly_created_Class_as_RESTful_service"> + <title>Deploying newly created Class as RESTful service</title> + <para> + To deploy script automatically at server startup time, its property exo:autoload must be set as true. org.exoplatform.services.jcr.ext.script.groovy.GroovyScript2RestLoader check JCR workspaces which were specified in configuration and deploy all auto-loadable scripts. + </para> + <para> + Example of configuration. + </para> + <programlisting language="XML" role="XML">&lt;component&gt; &lt;type&gt;org.exoplatform.services.jcr.ext.script.groovy.GroovyScript2RestLoader&lt;/type&gt; &lt;init-params&gt; @@ -156,92 +156,92 @@ &lt;/object-param&gt; &lt;/init-params&gt; &lt;/component&gt;</programlisting> - <para> - In example above JCR workspace "production" will be checked for autoload scripts. At once, this workspace will be listened for changes script's source code (property jcr:data). - </para> + <para> + In example above JCR workspace "production" will be checked for autoload scripts. At once, this workspace will be listened for changes script's source code (property jcr:data). + </para> - </section> - - <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Script_Lifecycle_Management"> - <title>Script Lifecycle Management</title> - <para> - If GroovyScript2RestLoader configured as was decribed in the previous section, then all "autoload" scripts deployed. In the first section, we added script from file /home/andrew/JcrGroovyTest.groovy to JCR node /script/groovy/JcrGroovyTest.groovy, repository repository, workspace production. In section "Load script via HTTP", it was referred about load scripts via HTTP, there is an opportunity to manage the life cycle of script. - </para> - <para> - Undeploy script, which is already deployed: - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + </section> + + <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Script_Lifecycle_Management"> + <title>Script Lifecycle Management</title> + <para> + If GroovyScript2RestLoader configured as was decribed in the previous section, then all "autoload" scripts deployed. In the first section, we added script from file /home/andrew/JcrGroovyTest.groovy to JCR node /script/groovy/JcrGroovyTest.groovy, repository repository, workspace production. In section "Load script via HTTP", it was referred about load scripts via HTTP, there is an opportunity to manage the life cycle of script. + </para> + <para> + Undeploy script, which is already deployed: + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ -X GET \ http://localhost:8080/rest/script/groovy/load/repository/production/scrip... - <para> - Then deploy it again: - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + <para> + Then deploy it again: + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ -X GET \ http://localhost:8080/rest/script/groovy/load/repository/production/scrip... - <para> - or even more simple: - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + <para> + or even more simple: + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ -X GET \ http://localhost:8080/rest/script/groovy/load/repository/production/scrip... - <para> - Disable scripts autoloading, NOTE it does not change current state: - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + <para> + Disable scripts autoloading, NOTE it does not change current state: + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ -X GET \ http://localhost:8080/rest/script/groovy/repository/production/script/gro... - <para> - Enable it again: - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + <para> + Enable it again: + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ -X GET \ http://localhost:8080/rest/script/groovy/autoload/repository/production/s... - <para> - and again more simple variant: - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + <para> + and again more simple variant: + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ -X GET \ http://localhost:8080/rest/script/groovy/autoload/repository/production/s... - <para> - Change script source code: - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + <para> + Change script source code: + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ -X POST \ -H 'Content-type:script/groovy' \ --data-binary @JcrGroovyTest.groovy \ http://localhost:8080/rest/script/groovy/update/repository/production/scr... - <para> - This example imitates sending data with HTML form ('multipart/form-data'). - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + <para> + This example imitates sending data with HTML form ('multipart/form-data'). + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ -X POST \ -F &quot;file=(a)JcrGroovyTest.groovy;name=test&quot; \ http://localhost:8080/rest/script/groovy/update/repository/production/scr... - <para> - Remove script from JCR: - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + <para> + Remove script from JCR: + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ -X GET \ http://localhost:8080/rest/script/groovy/delete/repository/production/scr... - </section> - - <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Getting_node_UUID_example"> - <title>Getting node UUID example</title> - <para> - Now we are going to try simple example of Groovy RESTfull service. There is one limitation, even if we use groovy, we should use Java style code and decline to use dynamic types, but of course we can use it in private methods and fields. Create file JcrGroovyTest.groovy, in this example I save it in my home directory /home/andrew/JcrGroovyTest.groovy. Then, configure GroovyScript2RestLoaderPlugin as described in section Load script at startup time. - </para> - + </section> + + <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Getting_node_UUID_example"> + <title>Getting node UUID example</title> + <para> + Now we are going to try simple example of Groovy RESTfull service. There is one limitation, even if we use groovy, we should use Java style code and decline to use dynamic types, but of course we can use it in private methods and fields. Create file JcrGroovyTest.groovy, in this example I save it in my home directory /home/andrew/JcrGroovyTest.groovy. Then, configure GroovyScript2RestLoaderPlugin as described in section Load script at startup time. + </para> + <programlisting language="Java" role="Java">import javax.jcr.Node import javax.jcr.Session import javax.ws.rs.GET @@ -277,28 +277,28 @@ ses.logout() } }</programlisting> - <para> - After configuration is done, start the server. If configuration is correct and script does not have syntax error, you should see next: - </para> - <mediaobject> - <imageobject> - <imagedata fileref="images/eXoJCR/groovy-console1.png" width="444" /> - </imageobject> + <para> + After configuration is done, start the server. If configuration is correct and script does not have syntax error, you should see next: + </para> + <mediaobject> + <imageobject> + <imagedata fileref="images/eXoJCR/groovy-console1.png" width="444" /> + </imageobject> - </mediaobject> - <para> - In the screenshot, we can see the service deployed. - </para> - <para> - First, create a folder via WebDAV in the repository production, folder name 'test'. Now, we can try access this service. Open another console and type command: - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + </mediaobject> + <para> + In the screenshot, we can see the service deployed. + </para> + <para> + First, create a folder via WebDAV in the repository production, folder name 'test'. Now, we can try access this service. Open another console and type command: + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ http://localhost:8080/rest/groovy/test/repository/production/test</pro... - <para> - When you try to execute this command, you should have exception, because JCR node '/test' is not referenceable and has not UUID. We can try add mixin mix:referenceable. To do this, add one more method in script. Open script from local source code /home/andrew/JcrGroovyTest.groovy, add following code and save file. - </para> - + <para> + When you try to execute this command, you should have exception, because JCR node '/test' is not referenceable and has not UUID. We can try add mixin mix:referenceable. To do this, add one more method in script. Open script from local source code /home/andrew/JcrGroovyTest.groovy, add following code and save file. + </para> + <programlisting language="Java" role="Java">@POST @Path("{path:.*}") public void addReferenceableMixin(@PathParam("repository") String repository, @@ -315,66 +315,66 @@ ses.logout() } }</programlisting> - <para> - Now we can try to change script deployed on the server without server restart. Type in console next command: - </para> - -<programlisting>andrew@ossl:~&gt; curl -i -v -u root:exo \ + <para> + Now we can try to change script deployed on the server without server restart. Type in console next command: + </para> + +<programlisting>user@host:~&gt; curl -i -v -u root:exo \ -X POST \ --data-binary @JcrGroovyTest.groovy \ -H 'Content-type:script/groovy' \ http://localhost:8080/rest/script/groovy/update/repository/production/scr... - <para> - Node '/script/groovy/JcrGroovyTest.groovy' has property exo:autoload=true so script will be re-deployed automatically when script source code changed. - </para> - <mediaobject> - <imageobject> - <imagedata fileref="images/eXoJCR/groovy-console2.png" width="444" /> - </imageobject> + <para> + Node '/script/groovy/JcrGroovyTest.groovy' has property exo:autoload=true so script will be re-deployed automatically when script source code changed. + </para> + <mediaobject> + <imageobject> + <imagedata fileref="images/eXoJCR/groovy-console2.png" width="444" /> + </imageobject> - </mediaobject> - <para> - Script was redeployed, now try to access a newly created method. - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + </mediaobject> + <para> + Script was redeployed, now try to access a newly created method. + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ -X POST \ http://localhost:8080/rest/groovy/test/repository/production/test</pro... - <para> - Method execution should be quiet, without output, traces, etc. Then we can try again get node UUID. - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + <para> + Method execution should be quiet, without output, traces, etc. Then we can try again get node UUID. + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ http://localhost:8080/rest/groovy/test/repository/production/test 1b8c88d37f0000020084433d3af4941f</programlisting> - <para> - Node UUID: 1b8c88d37f0000020084433d3af4941f - </para> - <para> - We don't need this scripts any more, so remove it from JCR. - </para> - -<programlisting>andrew@ossl:~&gt; curl -u root:exo \ + <para> + Node UUID: 1b8c88d37f0000020084433d3af4941f + </para> + <para> + We don't need this scripts any more, so remove it from JCR. + </para> + +<programlisting>user@host:~&gt; curl -u root:exo \ http://localhost:8080/rest/script/groovy/delete/repository/production/scr... - <mediaobject> - <imageobject> - <imagedata fileref="images/eXoJCR/groovy-console3.png" width="444" /> - </imageobject> + <mediaobject> + <imageobject> + <imagedata fileref="images/eXoJCR/groovy-console3.png" width="444" /> + </imageobject> - </mediaobject> + </mediaobject> - </section> - - <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Groovy_script_restrictions"> - <title>Groovy script restrictions</title> - <para> - You should keep one class per one groovy file. The same actually for interface and it implementation. It's limitation of groovy parser that does not have type Class[] parseClass(InputStream) or Collection parseClass(InputStream) but only Class parseClass(InputStream) instead. - </para> - <para> - That is all. - </para> + </section> + + <section id="sect-Reference_Guide-Groovy_Scripts_as_REST_Services-Groovy_script_restrictions"> + <title>Groovy script restrictions</title> + <para> + You should keep one class per one groovy file. The same actually for interface and it implementation. It's limitation of groovy parser that does not have type Class[] parseClass(InputStream) or Collection parseClass(InputStream) but only Class parseClass(InputStream) instead. + </para> + <para> + That is all. + </para> - </section> + </section> </chapter>