Project

General

Profile

Actions

Sample-groovy-in-Z2 » History » Revision 25

« Previous | Revision 25/29 (diff) | Next »
Henning Blohm, 22.04.2019 23:36


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.

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 18
master Java 11 ? Java 18

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.10.zip
unzip z2-base-v2.10.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.9 z2-base installation.

git clone -b v{{macro(2)}} http://git.z2-environment.net/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

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 over 5 years ago · 25 revisions