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.
NOTE: This sample has been discontinued as of v2.9.
Prerequisites¶
Z2 has the following Java Version requirements
Z2 Version | Min. Java version required | Max Java version supported | Max language level |
---|---|---|---|
2.1 - 2.3.1 | Java 6 | Java 7 | Java 7 |
2.4 - 2.5 | Java 8 | Java 8 | Java 8 |
2.6 | Java 9 | Java 11 | Java 10 |
2.7 | Java 9 | Java 11 | Java 11 |
2.8 | Java 9 | Java 13 | Java 13 |
2.9b | Java 8 | Java 8 | Java 8 |
2.9.1 | Java 11 | Java 16 | Java 15 |
2.9.1b | Java 8 | Java 8 | Java 8 |
2.10 | Java 11 | Java 18 | Java 18 |
2.10.1 | Java 11 | Java 21 | Java 18 |
master | Java 17 | ? | Java 23 |
Note: Most samples suggest to use the master branch. You may choose another version branch (please check the respective repository).
Make sure you have a corresponding Java Development Kit (JDK) or Java Runtime Environment (JRE) installed. If in doubt, go to Download Java SE.
Note: Running v2.1-v2.3.1 on Java 8 is supported by specifying
com.zfabrik.java.level=7
(or 6, if that is your desired compilation language level) in <home>/run/bin/runtime.properties
. By this the Java compiler version detection does not fall back to a lower level.
Setting up the sample¶
Here's the really fast version:
mkdir install
cd install
On Mac-OS or Linux run:
wget http://download.z2-environment.net/z2/z2-base-v2.8.zip
unzip z2-base-v2.8.zip
On Windows download the archive and unpack using the Windows explorer. Make sure to unpack into the installation folder previously created.
This will create a folder z2-base.core that contains the complete version 2.8 z2-base installation.
git clone -b v2.8 https://www.z2-environment.net/git/z2-samples.groovy
On Mac OS or Linux run:
cd z2-base.core/bin
./gui.sh
On Windows run:
cd z2-base.core\bin
gui.bat
(In order to check that z2 is up, when you see "Completed home process initialization", try http://localhost:8080/adm with user "z*" and password "z".)
The first time you launch the sample, it will take a while to download all required resources.
This sample highlights three things
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 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.
com.zfabrik.component.type=com.zfabrik.java java.privateReferences=\ com.zfabrik.servletjsp,\ com.zfabrik.groovy java.compile.order = groovy
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 is using plain Groovy (see project com.zfabrik.samples.groovy.web
) and the 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 First steps).
Make sure to have Groovy support installed with Eclipse (otherwise you will not have much fun with Groovy sources)!
Check Groovy_Add-on, if you have trouble running code in Eclipse.
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 and
- 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 script. Go to 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 for a trivial sample. Go 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 :
<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>
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 )
Using Spock Tests¶
The Spock Test Specification framework 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 that illustrates this combination:
@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 } }
If you have an Eclipse setup for this sample, as outlined above, you can run these tests directly from your IDE.
Updated by Henning Blohm about 3 years ago · 29 revisions