Groovy Server Pages Explained: Complete Guide to GSP in the Grails Framework

Groovy Server Pages (GSP) is a server-side view technology used mainly in the Grails framework. It lets developers combine HTML with Groovy code to create dynamic web pages. GSP files normally use the .gsp extension and are stored in the grails-app/views directory.

People search for GSP to understand how it works, how it differs from JSP, and whether it is still useful for modern Grails applications. This guide explains the main GSP concepts, including its syntax, built-in tags, forms, templates, layouts, security, performance, benefits, and limitations.

What Are Groovy Server Pages?

Groovy Server Pages, commonly called GSP, is a template technology for creating dynamic HTML on the server. It is closely associated with the Grails framework and normally acts as the View in the Model-View-Controller (MVC) pattern.

A GSP file can contain normal HTML along with Groovy expressions and special GSP tags. The server processes the file and turns it into HTML before sending the result to the browser. This makes GSP a server-side rendering technology.

GSP is similar in purpose to JavaServer Pages (JSP). The main difference is that GSP is built around the Groovy language and the Grails development model. This gives it direct access to many Grails features and conventions.

GSP files use the .gsp extension. In a normal Grails project, view files are placed inside grails-app/views/. For example, a book controller might have a view such as grails-app/views/book/list.gsp.

GSP runs on the Java Virtual Machine. One important change in its history is that GSP became an independent plugin rather than being bundled into the core Grails framework starting with Grails 3.3. This means developers may need to include the GSP plugin when creating or configuring a Grails application.

GSP is not a consumer service, website, or subscription product. It is a development technology. There is therefore no normal consumer pricing plan or country-based service availability to consider.

How GSP Works in the Grails Framework

GSP fits into the View part of the Grails MVC architecture. The basic process starts when someone opens a page or sends another HTTP request to a Grails application.

The browser sends the request to a controller. The controller processes the request and may retrieve information from a database through GORM, the Grails Object Relational Mapping system. It then prepares a model containing the information that the page needs.

That model is passed to a GSP view. The GSP combines the supplied data with its HTML markup and Groovy expressions. It then produces the final HTML response, which the server sends back to the browser.

For example, a controller action might return a book object:

def show() { [book: Book.get(params.id)] }

The related GSP can then display the book title with an expression such as:

${book.title}

Grails also uses Convention over Configuration. This means developers often do not have to manually tell Grails which view belongs to a controller action. If an action is called list(), Grails can look for a matching file such as:

grails-app/views/book/list.gsp

This convention reduces configuration and keeps Grails projects organized.

The complete flow can therefore be understood as:

Browser → Controller → Model/Data → GSP View → HTML → Browser

This separation is useful because the controller can focus on handling requests and preparing data while the GSP focuses mainly on displaying that data.

GSP Syntax: Expressions, Scriptlets, and Comments

GSP provides several ways to place dynamic content and Groovy-related instructions inside an HTML page. The most important syntax is the expression.

GSP Expressions

GSP expressions use ${}. They allow a Groovy expression to be evaluated and displayed in the generated HTML.

For example:

<p>Welcome, ${user.name}!</p> <p>Today is: ${new Date()}</p>

The expression can access objects supplied by the controller and can evaluate normal Groovy expressions. This is one of the simplest ways to display dynamic information.

GSP automatically HTML-encodes expression output by default. This behavior is important because it helps reduce the risk of malicious HTML being inserted into a page.

GSP Scriptlets

GSP also supports scriptlets using <% %> and output scriptlets using <%= %>.

For example:

<% out << “Hello from a scriptlet” %> <%= “Output this string” %>

Although this syntax is supported, official GSP guidance discourages using scriptlets for normal view development. GSP tags and custom tag libraries are preferred because they keep presentation code cleaner and make it easier to separate view logic from other application logic.

Server-Side Comments

GSP supports server-side comments with:

<%– This comment is removed before the response is sent –%>

These comments are not sent to the browser. This is different from an ordinary HTML comment, which can remain in the generated page source.

Page Directives

GSP also supports page directives. These can be used for tasks such as importing a class or declaring a content type.

For example:

<%@ page import=”java.text.SimpleDateFormat” %> <%@ page contentType=”application/json” %>

Groovy automatically imports many standard classes, so explicit imports are not always necessary.

Essential GSP Tags and Functions

GSP provides built-in tags that handle common tasks without requiring developers to write the same Groovy and HTML logic repeatedly. Grails GSP tags normally use the g: prefix and do not require import declarations.

Conditional Tags

The <g:if> and <g:else> tags allow a page to show different content depending on a condition.

For example:

<g:if test=”${session.role == ‘admin’}”> <a href=”/admin”>Admin Panel</a> </g:if> <g:else> <p>Access restricted.</p> </g:else>

This allows a GSP to change what it displays based on application data.

Looping With <g:each>

The <g:each> tag is used to loop through Groovy collections.

For example:

<g:each in=”${bookList}” var=”book”> <li>${book.title} by ${book.author}</li> </g:each>

This is useful when a controller sends a list of records to a view. The GSP can then display each item without writing a separate block of HTML for every record.

Creating Links With <g:link>

The <g:link> tag creates links based on Grails controllers and actions.

<g:link controller=”book” action=”show” id=”${book.id}”> View Book </g:link>

This approach avoids hardcoding every application URL. Grails can build the appropriate URL from the controller, action, and other supplied values.

Pagination With <g:paginate>

GSP also provides a pagination tag for displaying navigation between pages of results.

<g:paginate controller=”book” action=”list” total=”${bookCount}” />

The total value is required. Other options include max for the number of records per page, maxsteps for the number of pagination links, and prev and next for changing navigation labels.

There are also omitFirst and omitLast options for controlling first and last page links. The documented default for max is 10 records per page, while maxsteps defaults to 10.

These built-in tags are one reason GSP views can remain relatively compact. Common operations can be expressed with standard tags instead of repeated low-level code.

GSP Forms and User Input

GSP includes form tags for collecting information from users. These tags work naturally with Grails controllers and actions.

A basic form can use <g:form> together with fields such as <g:textField>, <g:checkBox>, <g:select>, and <g:submitButton>.

For example:

<g:form controller=”employee” action=”save”> First Name: <g:textField name=”fName” value=”${emp.fName}” /> Last Name: <g:textField name=”lName” value=”${emp.lName}” /> Active: <g:checkBox name=”active” value=”${emp.active}” /> Department: <g:select name=”dept” value=”${emp.dept}” from=”[‘Engineering’, ‘Sales’, ‘HR’]” /> <g:submitButton name=”submit” value=”Save” /> </g:form>

GSP also provides tags for password fields, hidden fields, radio buttons, and action-specific submit buttons. These include <g:passwordField>, <g:hiddenField>, <g:radio>, and <g:actionSubmit>.

The form tags mainly simplify the view side of form handling. The application still needs proper server-side validation and safe processing of the submitted values.

GSP Scopes, Parameters, and Data

GSP views can access several types of application data through different scopes. The five important scopes described in the Grails GSP model are params, request, session, flash, and application.

params

The params scope contains request parameters, including values supplied through URLs and forms.

request

The request scope holds information associated with the current HTTP request.

session

The session scope stores information associated with a particular user’s session.

flash

The flash scope is intended for short-lived information that can survive one redirect. It is often useful for messages such as a temporary success or error notice.

application

The application scope is used for information shared across the application.

GSP also provides <g:set> for creating variables within a view or assigning values to a particular scope. For example:

<g:set var=”now” value=”${new Date()}” scope=”request” />

These features make it possible for a GSP page to work with data prepared by controllers and other parts of the Grails application.

For maintainable applications, the view should mainly focus on presentation. Complex business rules and database operations are better handled elsewhere in the application rather than being placed directly inside GSP files.

GSP Templates and Reusable Views

GSP supports reusable templates for pieces of HTML that need to appear in multiple places. This helps reduce duplicate markup and makes large applications easier to maintain.

By convention, GSP template filenames begin with an underscore. A book-card template, for example, might be stored as:

grails-app/views/book/_bookCard.gsp

A template can then be rendered with <g:render>:

<g:render template=”bookCard” model=”[book: myBook]” />

GSP can also render a template against an entire collection:

<g:render template=”bookCard” var=”book” collection=”${bookList}” />

This is useful for repeated interface elements such as product cards, user records, book entries, or rows in a data-driven page.

Templates keep repeated presentation code in one place. If the design of a reusable component changes, developers can update the template instead of editing many separate pages.

GSP Layouts and Sitemesh

GSP supports layouts through Sitemesh, which allows developers to create a shared page structure around individual views.

A layout can contain common elements such as a header, navigation menu, footer, page title, and main content area. Individual GSP pages can then provide only the content that changes from page to page.

Grails layouts are normally stored in:

grails-app/views/layouts/

A layout can use tags such as <g:layoutTitle>, <g:layoutHead>, and <g:layoutBody> to insert information from the individual view. The default application layout is commonly:

grails-app/views/layouts/application.gsp

There are several ways to select a layout. A view can specify one with a meta tag, a controller can declare a layout, or Grails can select one through its naming conventions.

For example, a view can use:

<meta name=”layout” content=”main” />

A controller can also specify a layout, while Grails can look for a controller-specific layout automatically when conventions are followed.

GSP also provides <g:applyLayout> for applying a layout directly to a template or section.Groovy Server Pages Explained: Complete Guide to GSP in the Grails Framework

Custom Tag Libraries in GSP

Custom Tag Libraries, or TagLibs, let developers create their own reusable GSP tags. They are useful when the same presentation logic is needed in several views.

A custom TagLib is normally created as a Groovy class inside grails-app/taglib/. The class name convention ends with TagLib.

For example, a developer could create a tag that formats a date, displays a message, or creates a repeated piece of page content. The tag can then be used in a GSP file without importing the class manually.

This keeps GSP pages shorter and avoids copying the same view logic into many files. Custom tags are also a cleaner choice than putting large blocks of Groovy code directly inside a page.

GSP Performance and Compilation

GSP pages are compiled into Java classes instead of being processed as plain text on every request. Grails uses the GroovyPagesTemplateEngine and GroovyPagesServlet as part of this process. After compilation, the pages run within the JVM.

For production applications, GSP files can be precompiled during the build. This helps avoid compilation work when the application receives its first request.

During development, GSP can also reload changed files automatically. Settings such as grails.gsp.enable.reload, grails.gsp.reload.interval, and grails.gsp.reload.granularity control this behavior.

Frequent reloading during long development sessions can contribute to memory problems. If an application starts using too much memory after many reloads, restarting the server can help. These reload settings are mainly useful during development and should not be treated as a production performance feature.

GSP Security and XSS Protection

Security is an important part of server-side templates because application data is often placed directly into HTML.

GSP has automatic HTML encoding for ${} expressions. The supplied source notes that this behavior has been enabled by default since Grails 2.3. If a value contains HTML characters, encoding helps prevent that value from being treated as active HTML or JavaScript in the page.

GSP also provides URL encoding through tags such as <g:link>, <g:form>, and <g:createLink>. Additional encoding methods are available for specific situations, including HTML, URL, and JavaScript encoding.

Be Careful With raw()

GSP provides raw() when a developer intentionally wants to output HTML without normal encoding.

This can be useful for trusted HTML content, but it can also create an XSS problem if the content comes from an untrusted user. For this reason, raw() should not be used on user-submitted content unless it has been properly trusted or safely sanitized.

Automatic encoding is helpful, but it does not make an entire application secure. Developers still need proper input validation, authentication, authorization, CSRF protection, secure dependencies, and safe database practices.

GSP vs JSP vs React and Angular

GSP, JSP, React, and Angular can all be used to build web interfaces, but they work in different ways.

GSP is a natural choice when the application is already built with Grails. Its controller, GORM, view, and convention-based features work together closely.

React and Angular are more focused on component-based frontend development. They are often chosen when an application needs a highly interactive interface or a single-page application architecture.

The choice does not have to be completely separate. A Grails application can use GSP for server-rendered pages while also providing APIs for React or Angular. This allows different parts of the application to use the approach that fits them best.

Can GSP Run Without Grails?

Yes, but its usefulness is reduced outside the Grails framework.

GSP can technically run with a standard servlet container using groovy.servlet.TemplateServlet. It can also be integrated with Spring MVC or Spring Boot with additional configuration.

The problem is that many of GSP’s convenient features come from Grails.

Spring integration also requires manual configuration, including setting up the appropriate GSP template engine. Because of this, GSP is generally most useful when it is used as part of the Grails ecosystem.

Benefits and Drawbacks of GSP

Benefits

GSP has several practical advantages for Grails projects:

• It provides simple server-side rendering.

• It works closely with Grails controllers and GORM.

• Its Groovy syntax is concise and flexible.

• Built-in tags handle common tasks such as links, forms, loops, and pagination.

• Templates and layouts reduce repeated code.

• Automatic HTML encoding helps with safer output.

• JVM-based execution fits well with Java and Groovy applications.

• Grails scaffolding can quickly create common views for CRUD applications.

• It can be useful for rapidly building MVPs and traditional web applications.

Drawbacks

GSP also has limitations:

• Its biggest advantages depend on the Grails ecosystem.

• It is not as focused on highly interactive frontend applications as React or Angular.

• Running it outside Grails requires more setup.

• Scriptlets are supported but discouraged.

• Frequent development reloading can contribute to memory issues.

• Developers still need to understand web security instead of relying only on automatic encoding.

These limitations do not make GSP unsuitable. They simply mean that it works best for certain types of applications.

Who Should Use GSP?

GSP is mainly useful for developers working with Grails and other JVM-based applications.

It can be a good fit for:

• Grails developers

• Java or Groovy teams

• Server-rendered websites

• Database-driven applications

• CRUD systems

• Internal business applications

• Admin panels

• Rapid MVP development

In those cases, a framework such as React or Angular may be a better fit.

GSP Versions, Plugin Status, and Current Documentation

GSP has been distributed as an independent plugin since Grails 3.3 rather than being included directly in the core framework. The supplied source gives org.grails.plugins:gsp:6.2.3 as an example dependency and also mentions the org.grails.grails-gsp Gradle plugin.

That version should not automatically be considered the latest version. Developers should check the current official Grails and GSP documentation before adding a dependency to a new project.

The supplied source also references GSP documentation for Grails 7-related releases.

GSP Pricing, Licensing, Privacy, and Availability

GSP is a software development technology, so it does not work like a consumer service with monthly plans or regional subscriptions.

The provided material does not identify consumer pricing tiers or country restrictions. It also does not provide enough information to make a detailed current licensing statement.

Privacy is mainly determined by the application built with GSP.

Common GSP Problems and Troubleshooting Tips

GSP View Not Found

Check that the file is in the expected grails-app/views/ location and that its name matches the controller and action conventions.

Changes Are Not Appearing

During development, check whether GSP reloading is enabled and whether the reload interval is appropriate.

Memory Problems During Development

Long sessions with frequent GSP reloading can cause memory-related problems. Restarting the development server may clear the issue.

Unsafe HTML Output

Avoid using raw() with user-supplied content. Let normal HTML encoding handle untrusted values whenever possible.

Slow First Request

Production applications can precompile GSP files during the build to avoid first-request compilation work.

Problems Outside Grails

If GSP is being used without Grails, remember that some Grails features require manual configuration or may not be available in the same way.

GSP Best Practices

A few simple practices can make GSP applications easier to maintain and safer:

• Prefer GSP tags over scriptlets.

• Keep complex business logic outside the view.

• Use templates for repeated page components.

• Use layouts for shared page structures.

• Keep automatic HTML encoding enabled.

• Avoid raw() for untrusted content.

• Validate user input on the server.

• Use GSP URL helpers instead of unnecessary hardcoded paths.

• Precompile GSP files for production.

• Keep development reload settings for development use.

• Use custom TagLibs when reusable view logic is needed.

Following these practices keeps GSP pages focused on displaying information instead of becoming another place for complex application logic.

Bottom Line

Groovy Server Pages is a server-side template technology that works especially well with the Grails framework. It combines HTML with Groovy and provides useful features such as built-in tags, forms, templates, layouts, custom TagLibs, automatic encoding, and server-side rendering.

Its biggest advantage is its close connection with Grails. Developers can move data from controllers and GORM into views with relatively little setup. Its main limitation is that many of these conveniences are tied to Grails.

For a Grails application that needs traditional server-rendered pages, GSP remains a practical option. For applications that depend heavily on complex client-side interaction, a frontend framework such as React or Angular may be more suitable.

---

(FAQs)

What are Groovy Server Pages?

Groovy Server Pages, or GSP, is a server-side template technology mainly used with Grails. It combines HTML with Groovy expressions and GSP tags to generate dynamic web pages.

How does GSP work?

A Grails controller prepares data and sends it to a GSP view. GSP uses that data to create HTML, which is then returned to the browser.

What is the difference between GSP and JSP?

Both are server-side technologies, but GSP uses Groovy and is closely integrated with Grails. JSP is a Java web technology and is not tied to the Grails ecosystem.

Is GSP still useful in 2026?

It can still be useful for Grails applications, server-rendered websites, CRUD systems, and rapid MVP development. Its value depends on the application’s needs and architecture.

Is GSP secure?

GSP automatically HTML-encodes expression output by default, which helps reduce XSS risks. However, developers still need to follow normal web security practices and should be careful with functions such as raw().

Can GSP work with React or Angular?

GSP can provide server-rendered pages while Grails APIs serve data to React or Angular components. The two approaches can be used together.

---