z2-Environment

h1. Sample Groovy in Z2

This sample shows how to use the Groovy support, as implemented by the [[Groovy Add-on]].

This sample is stored in the repository "z2-samples-groovy":https://redmine.z2-environment.net/projects/z2-samples/repository/z2-samples-groovy. 

h2. Prerequisites

{{include(Java_Version_Requirements)}}

h2. Setting up the sample

Here's the really fast version:

{{include(Install_sample_prefix)}}

<pre><code class="ruby">

git clone -b v{{include(Latest_Version)}} http://git.z2-environment.net/z2-samples.groovy

</code></pre>

{{include(Install_sample_postfix)}}

The first time you launch the sample, it will take a while to download all required resources.

This sample highlights three things

h2. Using Groovy or Java or any mix of the two

When declaring to use the groovy compiler as in "/com.zfabrik.samples.groovy_and_java.web/java/z.properties":https://redmine.z2-environment.net/projects/z2-samples/repository/z2-samples-groovy/revisions/master/entry/com.zfabrik.samples.groovy_and_java.web/java/z.properties you can mix Java and Groovy as you like. The Groovy compiler support will figure out whether a Java component (which may then be not Java only anymore - strictly speaking) contains only Java sources, only Groovy sources, or a mix of both.

<pre>

com.zfabrik.component.type=com.zfabrik.java

java.privateReferences=\

	com.zfabrik.servletjsp,\

	com.zfabrik.groovy

java.compile.order = groovy

</pre>

As in the sample, it is mandatory to reference *com.zfabrik.groovy* (a module providing groovy-all and some more) for any part that contains groovy sources.

The sample apps just print the HTTP request header - the "http://localhost:8080/plain-groovy-sample":http://localhost:8080/plain-groovy-sample is using plain Groovy (see project @com.zfabrik.samples.groovy.web@) and the "http://localhost:8080/groovy-java-sample/":http://localhost:8080/groovy-java-sample/ is using a mixture of Groovy and Java sources (see project @com.zfabrik.samples.groovy_and_java.web@). Note that while the former project is compiled using the plain Groovy compiler the latter is compiled using the Joint Groovy/Java Compiler.

If you want to inspect the code using Eclipse, please create a workspace in install (i.e. @install/workspace@) and import the Git repositories and the following  projects into your workspace: _core_ from z2-base.core, _environment_ and _com.zfabrik.samples.groovy.web_ from z2-samples.groovy (see also [[Step_3_-_First_steps_with_Z2_on_Git|First steps]]).

Make sure to have "Groovy support":https://github.com/groovy/groovy-eclipse/wiki installed with Eclipse (otherwise you will not have much fun with Groovy sources)!

Check [[Groovy_Add-on#Trouble-Shooting]], if you have trouble running code in Eclipse.

h2. Using Groovlets and Groovy Template Pages

Generally, the mere fact that groovy-all is available implies that generally speaking all features described in 

* "http://docs.groovy-lang.org/latest/html/documentation/servlet-userguide.html":http://docs.groovy-lang.org/latest/html/documentation/servlet-userguide.html and

* "http://docs.groovy-lang.org/latest/html/documentation/template-engines.html":http://docs.groovy-lang.org/latest/html/documentation/template-engines.html

work. Groovlets are groovy scripts that are turned into Servlets on the fly. The same header list as above is created by the "headers.groovy":https://redmine.z2-environment.net/projects/z2-samples/repository/z2-samples-groovy/revisions/master/entry/com.zfabrik.samples.groovy.web/web/WebContent/headers.groovy script. Go to "http://localhost:8080/plain-groovy-sample/headers.groovy":http://localhost:8080/plain-groovy-sample/headers.groovy to see it running.

Similarly, the Groovy equivalent of Java server pages, Groovy Template Pages are supported. The author has not looked deeply into this. But check out "index.gsp":https://redmine.z2-environment.net/projects/z2-samples/repository/z2-samples-groovy/revisions/master/entry/com.zfabrik.samples.groovy.web/web/WebContent/index.gsp for a trivial sample. Go "http://localhost:8080/plain-groovy-sample/index.gsp":http://localhost:8080/plain-groovy-sample/index.gsp to see it running.

To turn on support for Groovlets and GSPs, corresponding servlets and resource mappings have to be defined in the web app's "web.xml:https://redmine.z2-environment.net/projects/z2-samples/repository/z2-samples-groovy/revisions/master/entry/com.zfabrik.samples.groovy.web/web/WebContent/WEB-INF/web.xml :

<pre  class="xml">

    <servlet>

            <servlet-name>Groovy</servlet-name>

            <servlet-class>com.zfabrik.groovy.servlet.ContextAwareGroovyServlet</servlet-class>

    </servlet>

    <servlet>

           <servlet-name>GroovyTemplate</servlet-name>

           <servlet-class>groovy.servlet.TemplateServlet</servlet-class>

    </servlet>

    <servlet-mapping>

            <servlet-name>Groovy</servlet-name>

            <url-pattern>*.groovy</url-pattern>

    </servlet-mapping>

    <servlet-mapping>

            <servlet-name>GroovyTemplate</servlet-name>

            <url-pattern>*.gsp</url-pattern>

    </servlet-mapping>

</pre>

*Note:* Instead of using the standard Groovy Servlet (implementing Groovlets support), we use a specialized version that is part of the @com.zfabrik.groovy@ module. This is so that application types will be found correctly. Inquiry with the Groovy community in under way (see also #1042)

h2. Using Spock Tests

The "Spock Test Specification framework":http://code.google.com/p/spock/ provides an elegant way to specify and implement test cases over - in the end - the JUnit framework that is well integrated in virtually any Java capable development environment. Z2 integrates with JUnit via z2Unit (see [[How to z2Unit]]) to allow server-side unit tests. 

Quite elegantly, the only declaration that differentiates a Spock test from any old JUnit test is the mentioning of Spock's JUnit runner called Sputnik. When you write a local Spock tests, this is implicitly applied via the Spock test super class @Specification@. Now z2Unit uses a JUnit runner itself to shift test execution from the invoking VM to the Z2 VM. The solution to that seeming conflict is indeed straight-forward: Declare the z2Unit test runner to have execution handed over, and tell z2Unit to use Sputnik when executing a test class within Z2. 

The sample module @com.zfabrik.samples.spock@ contains a test class "HelloSpockZ2":https://redmine.z2-environment.net/projects/z2-samples/repository/z2-samples-groovy/revisions/master/entry/com.zfabrik.samples.spock/java/src.test/com/zfabrik/samples/spock/tests/HelloSpockZ2.groovy that illustrates this combination:

<pre  class="groovy">

@RunWith(Z2UnitTestRunner.class)

@Z2UnitTest(componentName="com.zfabrik.samples.spock", runWith=Sputnik.class)

class HelloSpockZ2 extends Specification {

	def "A first test that should pass"() {

		setup:

			def x = new ArrayList<String>();

		when:

			x.add("Hello")

		then:

			x.size() == 1

	}

	def "a second test that should fail"() {

		setup:

			def x = new ArrayList<String>();

		when:

			x.add("Hello")

		then:

			x.size() == 2

	}

}

</pre>

If you have an Eclipse setup for this sample, as outlined above, you can run these tests directly from your IDE.

</pre>