Groovy and Tomcat, Pt1 – Calling Groovy from a Java Servlet

For this first post, I’ll keep it very simple: a Java servlet calls Groovy code to display a message to the screen. Start by setting up a regular Java servlet application. After your simple web application is set up, read the code snippets below.


index.jsp

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<html>
<head>
<title>Eek's Groovy Sandbox</title>
</head>
<body>
<p>I'm using <c:out value="${language}" />! That's <c:out value="${sentiment}" /></p>
<p><c:out value="${message}" /></p>
</body>
</html>

In this .jsp code, we’ll print three attributes. Two handled by the Java servlet and one handed to us by our Groovy utility class.

The Java servlet


package net.mymilkedeek.tomcat;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

/**
 * The Java Servlet
 *
 * @author My Milked Eek
 */
public class JavaServlet extends HttpServlet {
 @Override
 protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
 req.getSession().setAttribute("language", "java");
 req.getSession().setAttribute("sentiment", "ok...");
 resp.sendRedirect("index.jsp"); }
}

web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
 http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
 version="2.5">

<servlet>
 <servlet-name>JavaServlet</servlet-name>
 <servlet-class>net.mymilkedeek.tomcat.JavaServlet</servlet-class>
 </servlet>
 <servlet-mapping>
 <servlet-name>JavaServlet</servlet-name>
 <url-pattern>/javacallinggroovy</url-pattern>
</servlet-mapping>

</web-app>

That’s a simple webapplication. Now add the following dependencies to your project:

– groovy.jar
– antlr.jar
– asm.jar

Now add a Groovy Class, I named it JavaGroovy.

Groovy Class

package net.mymilkedeek.tomcat

class JavaGroovy {

static def message() {
 "I was called from Groovy. Exciting, isn't it?"
 }
}

And add following line to your Java Servlet:

...
req.getSession().setAttribute("message", JavaGroovy.message());
...

Now, navigate to the url of the Java Servlet and watch the magic happen:

So, in short, what we did was make a call to a Java Servlet. This servlet then gets a message from a Groovy class. And then we added that message to the session.

This kind of setup with Groovy is particularly useful with an existing Java Servlet: You only need to add Groovy jars and you can start hacking away.

For my next post, I’ll show you how to get Groovy extending HttpServlet.

Stay tuned,
Eek.

Groovy and Tomcat

It’s been a while since my last non-ludum blog post. Since I wrote “iText on the JVM” I’ve been playing with Groovy and Python occasionally. But for the past month and a half, I’ve been getting into Groovy a lot. So much that my next Ludum Dare entry will be written in Groovy/Java.

Up until this blog post I’ve just been experimenting with Groovy, using it to quickly test issues and bugs, but I wanted to do a bit more with it, so I tried using it in Tomcat. I didn’t set up Grails, didn’t want to do that just yet, but I set up Groovy and I’ll document several ways to use Groovy in Tomcat.

Table of contents:

  1. Java HttpServlet calling Groovy
  2. Groovy HttpServlet
  3. Groovy Scripts
  4. Groovy Servlet Pages
  5. Bringing it all together

We’ll start out really simple; use Groovy as an extension to an existing Java servlet and work our way to using scripts in combination with .gsp’s.

Stay tuned,
Eek.

Ludum 23 #04 – Day 2

Going, going… going…

 

So it’s going to be a basic rpg. Hp, atk, def. And that’s it. If I have time to spare, some weapon or something. Only things on the todo list:

– battle screen
– map (graphics and tiling)
– story (intro)
-victory conditions

Ludum Dare #03 – End of Day 1

I. HATE. COLLISION. DETECTION.

qfzmerkjgfnaùekgfn

So, APPARENTLY, the map hangs when trying to render its edge. And somehow that makes the interface skewed. Which made the collision map incorrect. After hours of trying to fix this by some freakmath, freakmath as in “what am I doing here” and not as in “genius!”, the most simple answer too my issue was to simply increase the map so that the borders aren’t visible.

Problem? MAKE BIGGER THINGS.  Still a problem? BLOW IT UP.

Text rendering and processing works. Near perfect in fact. The only flaw my system has that it’s rather hardcoded. AH WELL.

I implemented a quick battle algorithm, so I’d just need to make the screen in the morning. Add story, graphics, victory condition and whatever.

I’m a bit too tired. See you tomorrow.

Ludum Dare #01 – 8.5 hours in

So, as I’m getting ready to have some lunch, let’s reflect on what we have at the moment:

– map rendering works perfectly, I implemented a partial view of a map, so it will scroll along when the player moves.
– sprited animation, one slight bug in the sprite while moving, nothing to worry about at this time.
– collision detection, I only need to fix an offset on the collision map. As it is now, the collision map is offset by about half a map. But the upside is: it works.

Compared to last time, not taking art into account, HAH “art” he says, I’m about as far as I got last time in Ludum engine-wise.

On the TODO list until the next blog update:

– fix that collision bug
– movement to other maps, not sure how to do that just yet, but I will need to get that working before moving on
– generic display of text
– decide on genre. RPG or Action/Adventure.

That’s about what I’ll do until the next update. Now, until I wait for lunch to be served (yes served :awesomeface:) I’m going to clean my code a bit. It’s beginning to reek.