In my current project we have a need to generate a set of files for each environment, using templates. As this is a
Gradle project, this requirement is easily accomplished with a CopyTask
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
The processTemplates
task above will copy all files from src/templates
to build/output/<envName>
. All files whose
name ends with .template
will be processed and tokens (ex: ${variable}
) will be replaced by their values from the
env/<envName>.properties
file. Adding the properties file as an input for the task is important (inputs.file
method
call), so when you change it, the task will be re-executed on the next build.
Simple, right?
This worked fine until we had one template that was really big (120KB) and we found out about issue GRADLE-3122. Gradle uses Groovy’s SimpleTemplateEngine, that can only process files up to 64KB!
Newest versions of Groovy (2.4+) include StreamingTemplateEngine that does not have this limit, but the most recent version of Gradle (2.5 as of this post) still uses Groovy 2.3…
One way to overcome this would be to use Ant’s ReplaceTokens
filter, simply by changing our templates to use Ant’s
token syntax (ex: @variable@
) and changing the line expand(env)
to filter(ReplaceTokens, tokens: env)
But because we need to use logic in our templates (if’s and loops), we had to come up with a different approach. The solutions available were too simple for our needs or too complicated to implement in a clear way, making them unsuitable for our project. So we decided to roll…
Finally we decided to implement a simple template processor using FreeMarker. We select this awesome template engine for its feature set, IDE support and excelent OSS reputation, although the solution bellow could be adapted to be used with any other template engine (Velocity, JMustache, etc…)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
|
Note that we now use the .ftl
file extension for our templates, to enable support in our
IDE of choice. To use the processor, you have to put it under the
buildSrc project.
This is a special “module” in your project that is a simple way to organize build logic in your build scripts. It is
all automatically handled by Gradle. You’ll also need a small build.gradle
just for declaring the dependencies for
FreeMarker and Apache Commons IO (used for the copyFile
method):
1 2 3 4 5 6 |
|
To have this code available to your main build script, add this two files in your project, in the following paths:
The last step is to actually use it in our processTemplates
task:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Not hard, eh? Note that this task is not a CopyTask
anymore, so we now need to specify its inputs and outputs.
My plan is to convert this code into a proper Gradle plugin. But for now: That’s all, folks!
]]>The data should be: código redome;;código hemocentro;nome;nome da mãe;
The file was generated with Windows Excel, using the encoding ISO-8859-2
(common encoding for Windows). After some investigation I found
out that Fileupload by default treats all files with content type text/...
as UTF-8! Ouch!!
If all your files will be generated using the same file encoding, this can be fixed with the following configuration:
1 2 3 4 5 6 7 |
|
The upload-charset tag did the trick! But what if my user decides to move to a different (better?) platform in the future, and generates the file with UTF-8? Or any other encoding?
Then the proper solution is to use the tag upload-charset-finder-class:
1
|
|
The documentation says that this class has to implement
the interface CharsetFinder
and its sole method String getCharset(String contentType, InputStream content)
:
When a text file is uploaded, the getCharset method is called and it can determines the encoding based on the content type and/or the content of the uploaded file.
Which leads us to the main reason of this post: How to detect the file encoding, if ZK itself does not provide a default implementation for this interface?
More research pointed me to some solutions, but the one that I ended up implementing was using the
Apache Any23. It includes the TikaEncodingDetector
,
that can be used to auto-detect the file encoding of a stream. The final code
for the CharsetFinder implementation is the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Yep, it is that simple. The final ZK configuration to use this class is:
1 2 3 4 5 6 7 |
|
class UtilFilters {
def filters = {
profiler(controller: '*', action: '*') {
before = {
request._timeBeforeRequest = System.currentTimeMillis()
}
after = {
request._timeAfterRequest = System.currentTimeMillis()
}
afterView = {
if (params.showTime) {
session._showTime = params.showTime == "on"
}
if (session._showTime) {
def actionDuration = request._timeAfterRequest - request._timeBeforeRequest
def viewDuration = System.currentTimeMillis() - request._timeAfterRequest
log.debug("Request duration for (${controllerName}/${actionName}): ${actionDuration}ms/${viewDuration}ms")
}
}
}
}
}
To use it, put this class in the grails-app/conf
folder of your project. To activate the profile, call any URL
of your application with the showTime=on
parameter, like this:
1
|
|
After calling that URL, all request times will be measured and informed on the application’s log, like this:
1
|
|
The first time informed (20ms) is the time spent executing the action (list in this case) and the second (50ms) is
the time spent rendering the view (list.gsp
).
To turn off the profiler, call any URL with showTime=off
:
1
|
|
Enjoy :)
]]>This week I tried the Marc Palmer’s excelent plugin Cache-Headers, and it really rocks! Using it I can make all my server-side generated images be cached on the client, reducing significantly the bandwidth and cpu-power necessary by my application.
But there’s a little gotcha: The plugin (as of version 1.1.2) uses a SimpleDateFormat to generate and check the Last-Modified header, and the implementation creates this SimpleDateFormat with the system’s default Locale, in my case Portuguese. This causes errors like this:
1 2 3 4 5 6 7 8 9 |
|
The workaround I found was to override the construction of that SimpleDateFormat. Luckily it’s been created in a small class, that is easy to extend:
package com.deluan.grails.util
import java.text.SimpleDateFormat
import com.grailsrocks.cacheheaders.DateFormatterThreadLocal
/**
* This class is used to force CacheHeadersService (from the cache-headers
* plugin) to generate http-dates in english. It MUST be used when the
* locale of your server is not English.
* <p/>
* To use it, put the following configuration in your Config.groovy:
* <pre>
* beans {
* cacheHeadersService {
* dateFormatters = new com.deluan.grails.util.EnglishDateFormatterThreadLocal()
* }
* }
* </pre>
*
* @author Deluan
*/
class EnglishDateFormatterThreadLocal extends DateFormatterThreadLocal {
SimpleDateFormat initialValue() {
def v = new SimpleDateFormat(RFC1123_DATE_FORMAT, Locale.ENGLISH)
v.timeZone = TimeZone.getTimeZone('GMT')
return v
}
}
All you have to do is put this class in your project (in the src/groovy
folder) and add the following configuration
override in your Config.groovy
:
1 2 3 4 5 |
|
I already filled a bug report here: http://jira.codehaus.org/browse/GRAILSPLUGINS-2707, and probably this post will be obsolete in a near future :)
]]>First, a small introduction. You can skip it and go straight to the source code, if you want.
I started working with Apache Shiro when it was still called JSecurity, and I have to say that it really rocks! I tried to use Spring Security (Acegi) in some projects, but the easiness and lean approach of Shiro is unbeatable. For a quick introduction, here’s a quote from the project’s site:
Apache Shiro is a powerful and easy-to-use Java security framework that performs authentication, authorization, cryptography, and session management.
With Shiro’s easy-to-understand API, you can quickly and easily secure any application – from the smallest mobile applications to the largest web and enterprise applications.
I’ve used it in Java and Grails projects, and recently I’ve even been experimenting it with Google App Engine. It fits very well in almost any Java platform project that needs security.
Shiro already works great in a JSF/Facelets project. You can use its filters to grant and deny access to some parts of your application and to force authentication (redirect to login).
The only functionality missing is the power of its JSP taglib, that is used to conditionally render some parts of your HTML, based on user’s authorization, roles and permissions (you can learn how to use them with this simple example project). The problem is that this conditional rendering is not totally compatible with JSF’s phases. Better than trying to fit a cube into a spherical hole, I decided to rewrite Shiro’s JSP tags into a Facelets taglib, totally compatible with JSF.
All original tags are available as their Facelets equivalents, and I have introduced two new ones:
<shiro:hasAnyPermission>
- Displays body content only if the current user has one of the specified permissions from
a comma-separated list of permission strings.
<shiro:remembered>
- Displays body content only if the current user has a known identity that has been obtained from
‘RememberMe’ services. Note that this is semantically different from the <shiro:authenticated>
tag, which is more restrictive.
I’ve already submitted a patch to Shiro’s development team, but they’re very busy at the moment packaging the new 1.1 version for release. So I decided to share the taglib on GitHub, and host the artifacts in my personal maven repository, as I need to use the tags in an on-going project.
If you want to try it in your maven project, add my repository to your pom.xml:
<repositories>
<repository>
<snapshots>
<enabled>false</enabled>
</snapshots>
<id>bintray-deluan-maven</id>
<name>bintray</name>
<url>http://dl.bintray.com/deluan/maven</url>
</repository>
</repositories>
and add the jar dependency:
<dependency>
<groupId>org.apache.shiro</groupId>
<artifactId>shiro-faces</artifactId>
<!-- See the latest version on the project's homepage -->
<version>2.0</version>
</dependency>
Now you can declare Shiro’s namespace in your xhtml pages and use the tags like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:shiro="http://shiro.apache.org/tags">
<head>
<title><ui:insert name="titulo">Shiro Faces Test</ui:insert></title>
</head>
<body>
<p>Hi, <shiro:guest>Guest</shiro:guest>
<shiro:user><shiro:principal/></shiro:user>!
</p>
</body>
</html>
That’s it! Just keep in mind that as soon as this lib gets incorporated officially in Shiro, I’ll stop updating it in GitHub and all future enhancements will only be available in the official version. If you want to see the tags incorporated officially into Shiro sooner than later, you can vote here: https://issues.apache.org/jira/browse/SHIRO-206
And if you have any suggestion, please let me know.
Enjoy ;)
]]>Here’s a little tutorial on how to configure Spring in your Gaelyk project. I’m assuming you have basic knowledge of Spring, Gaelyk and Maven.
First, let’s create a Gaelyk project. The easiest way is using the excellent maven-gaelyk archetype:
1
|
|
Now open the project in your favorite IDE, so we can edit the configuration files. First, add the Spring dependency to your pom.xml
:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>${spring.version}</version>
</dependency>
Next we need to configure Spring’s ContextLoaderListener in web.xml
:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/spring/*.xml
</param-value>
</context-param>
<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
As you can see from above, we configured Spring to load all context configuration files under the directory WEB-INF/spring
.
With these configurations in place, your project is already Spring enabled. Now we need a easy way to access the
Spring’s Application Context. One good way to do this is using a singleton that implements the ApplicationContextAware
interface. To keep this post as small as possible, I borrowed an implementation from
this blog post, where you can learn
more about the details. Create the directory src/main/groovy
and put the following SpringApplicationContext singleton
there (in the correct package):
package com.deluan.gaelyk;
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
/**
* Wrapper to always return a reference to the Spring Application Context from
* within non-Spring enabled beans. Unlike Spring MVC's WebApplicationContextUtils
* we do not need a reference to the Servlet context for this. All we need is
* for this bean to be initialized during application startup.
*
* Original from http://sujitpal.blogspot.com/2007/03/accessing-spring-beans-from-legacy-code.html
*/
public class SpringApplicationContext implements ApplicationContextAware {
private static ApplicationContext CONTEXT;
/**
* This method is called from within the ApplicationContext once it is
* done starting up, it will stick a reference to itself into this bean.
* @param context a reference to the ApplicationContext.
*/
public void setApplicationContext(ApplicationContext context) throws BeansException {
CONTEXT = context;
}
/**
* This is about the same as context.getBean("beanName"), except it has its
* own static handle to the Spring context, so calling this method statically
* will give access to the beans by name in the Spring application context.
* As in the context.getBean("beanName") call, the caller must cast to the
* appropriate target class. If the bean does not exist, then a Runtime error
* will be thrown.
* @param beanName the name of the bean to get.
* @return an Object reference to the named bean.
*/
public static Object getBean(String beanName) {
return CONTEXT.getBean(beanName);
}
public static ApplicationContext getContext() {
return CONTEXT;
}
}
Configure the singleton in your spring context:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="springApplicationContext" class="com.deluan.gaelyk.SpringApplicationContext"/>
<bean id="dateFormat" class="java.text.SimpleDateFormat">
<constructor-arg value="yyyy/MM/dd" />
</bean>
<bean id="timeFormat" class="java.text.SimpleDateFormat">
<constructor-arg value="hh:mm:ss" />
</bean>
<bean id="dateTimeFormat" class="java.text.SimpleDateFormat">
<constructor-arg value="yyyy/MM/dd hh:mm:ss" />
</bean>
</beans>
As you can see, I also declared some SimpleDateFormat instances as beans to be used in our examples.
Now everything is configured and ready to be used. Let’s see how we can obtain a spring bean inside a Groovlet.
Create the file WEB-INF/groovy/index.groovy
with the following content:
import com.deluan.gaelyk.SpringApplicationContext
def dateFormat = SpringApplicationContext.getBean('dateFormat')
def now = new Date()
println dateFormat.format(now)
Now run your application with the command mvn gae:run
, point your browser to http://localhost:8080/index.groovy and
you should see something like this:
Well, that’s it! Nothing much different from what you are used to do in a normal Web application, right? But remember: Gaelyk is NOT your normal Web framework so let’s spice things a little bit.
The solution for looking up beans depicted above is a bit cumbersome. Let’s use
Gaelyk’s plugin system to make things a little more “groovy”.
Using the plugin descriptor bellow, we can provide shortcuts to our SpringApplicationContext’s methods, getContext()
and getBean(). Save it in the file WEB-INF/plugins/spring.groovy
:
import com.deluan.gaelyk.SpringApplicationContext
binding {
appCtx = SpringApplicationContext.context
getBean = {
SpringApplicationContext.getBean(it)
}
autowire = { self, beanNames ->
beanNames.each {
self.setProperty(it, SpringApplicationContext.getBean(it))
}
}
}
Before you can use these shortcuts, you need to tell Gaelyk about your descriptor by “installing” it in your project.
Save the code bellow in the file WEB-INF/plugins.groovy
:
install spring
Now you can use the shortcuts in your Groovlets this way:
def now = new Date()
// Simple context lookup
def dateFormat = getBean('dateFormat')
// Resolve a list of bean names and create bindings for each one of them
autowire this, ['timeFormat', 'dateTimeFormat']
html.html {
body {
p appCtx.displayName // Access the ApplicationContext
p dateFormat.format(now)
p timeFormat.format(now)
p dateTimeFormat.format(now)
}
}
Cool, isn’t it? A note on the autowire
binding: It creates bindings “automagically” for each bean you passed as a
parameter, as if the beans were declared in your Groovlet.
You can download the sample project used in this post from GitHub: http://github.com/deluan/gaelyk-spring. You can follow each commit to see exactly what was changed in each step of this tutorial.
If you have any suggestion or question, please let me know.
UPDATE: I’ve refactored the autowire
method into a Category, so now it’s not necessary to pass this
as the first
parameter. The new version is available at GitHub
Now that I decided to organize and publish some of my code/hacks here, I thought it would be a good thing to republish here my Grails caller script.
I work on and maintain various Grails projects at the same time, and some of them uses versions of Grails as old as 1.0.3! So the question is: How to call the right version of grails command for a given project, the version that the project was created with?
First I tried changing the GRAILS_HOME
environment variable every time I was
going to work with a project that uses a different version than the default.
But it’s just too much work for a thing that should be transparent. So I decided
to create a shell script to solve this problem. The script should detect which
Grails version to call when it’s executed. Here’s the script I came up with:
#!/bin/sh
# Author: Deluan (http://techbeats.deluan.com)
# Check if GRAILS_HOME is set
if [ -z "$GRAILS_HOME" -o ! -d "$GRAILS_HOME" ]; then
echo "Error: GRAILS_HOME not set"
exit 2
fi
# Extract the base path from GRAILS_HOME
BASE_GRAILS_PATH=`echo $GRAILS_HOME | sed -e "s/[^\/\\]*$//" -e "s/^$/./"`
APP_PROP="application.properties"
# Try to get the version from the command line
TRY_VERSION=$1
if [ -d "${BASE_GRAILS_PATH}/grails-${TRY_VERSION}" ]; then
VERSION=$TRY_VERSION
shift
fi
# Or else get the version from the application.properties in the current directory
[ -z "$VERSION" -a -f "$APP_PROP" ] &&
VERSION=`awk -F'=' '/app.grails.version/ { print $2 }' $APP_PROP | tr -d '\r\n'`
# Or else use the default version
if [ -z "$VERSION" ]; then
VERSION=`basename $GRAILS_HOME | cut -f 2 -d "-"`
fi
export GRAILS_HOME=${BASE_GRAILS_PATH}/grails-${VERSION}
GRAILS_CMD=${GRAILS_HOME}/bin/grails
if [ ! -x "$GRAILS_CMD" ]; then
echo "Error: grails command not found at '$GRAILS_CMD'!"
exit 3
fi
exec $GRAILS_CMD $*
The script first checks if you specified a version in the command line,
like: grails 1.3.5-SNAPSHOT create-app
. If not, it looks for an
application.properties
file in the current folder. This file keeps some
metadata for Grails projects, including the Grails version the project was
created with. If it does not find any application.properties
in the current
folder, it then just calls the
default Grails installed in your system,
the one that GRAILS_HOME
points to.
1 2 3 4 5 |
|
GRAILS_HOME
environment variable must be set and point to your “default”
Grails installation
This script was tested on Mac OS X (Snow Leopard), Linux (Ubuntu) and Windows (with cygwin)
PATH
.$GRAILS_HOME/bin
from your PATH
Using the script is as transparent as possible:
1
|
|
I searched for a Grails plugin that could help me with this, with no luck. Then I remembered that a Grails application is just a Spring application in disguise, so I looked for a Spring way to do this.
There are at least two ways to do this using Spring: Log4jConfigListener and Log4jConfigurer. I chose the later because the former assumes an expanded WAR file, which was not my case.
Here’s the recipe I came up with:
grails-app/conf/resources.groovy
:
(click here for a xml version)beans = {
log4jConfigurer(org.springframework.beans.factory.config.MethodInvokingFactoryBean) {
targetClass = "org.springframework.util.Log4jConfigurer"
targetMethod = "initLogging"
arguments = ["classpath:myapp/log4j.properties"]
}
...
}
Install the templates in your project with grails install-templates, so you can change some files used for Grails’ code generation. The one we are interested in is the web.xml template.
Comment out the Grails’ Log4jConfigListener from the src/templates/war/web.xml
template:
<filter-mapping>
<filter-name>sitemesh</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<!-- Comment this out!
<listener>
<listener-class>org.codehaus.groovy.grails.web.util.Log4jConfigListener</listener-class>
</listener>
-->
<listener>
<listener-class>org.codehaus.groovy.grails.web.context.GrailsContextLoaderListener</listener-class>
</listener>
You can (and should) remove the log4j configuration block from your Config.groovy
That’s it!
This was tested with Grails 1.3.3, deploying to an Oracle WebLogic 10.3.0 container.
]]>I think it’s time to start giving back some contribution, and here’s the first one: A Permalink Codec to generate permalinks based on strings. It strips out all non word chars and convert the resulting string to lowercase:
/*
* Copyright 2010 Deluan Cotts (grails@deluan.com.br)
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package com.deluan.grails.codecs
import java.util.regex.Matcher
import java.util.regex.Pattern
/**
* Strip all non word chars, convert to lowercase
*/
class PermalinkCodec {
private static final String[] CARACTERES_SEM_ACENTO
private static final Pattern[] PATTERNS
static {
CARACTERES_SEM_ACENTO = ["a", "e", "i", "o", "u", "c", "n"]
PATTERNS = new Pattern[CARACTERES_SEM_ACENTO.length]
PATTERNS[0] = Pattern.compile("[áàãâä]", Pattern.CASE_INSENSITIVE)
PATTERNS[1] = Pattern.compile("[éèêë]", Pattern.CASE_INSENSITIVE)
PATTERNS[2] = Pattern.compile("[íìïî]", Pattern.CASE_INSENSITIVE)
PATTERNS[3] = Pattern.compile("[óòöõô]", Pattern.CASE_INSENSITIVE)
PATTERNS[4] = Pattern.compile("[úùüû]", Pattern.CASE_INSENSITIVE)
PATTERNS[5] = Pattern.compile("ç", Pattern.CASE_INSENSITIVE)
PATTERNS[6] = Pattern.compile("ñ", Pattern.CASE_INSENSITIVE)
}
private static String replaceSpecial(String text) {
String result = text
for (int i = 0; i < PATTERNS.length; i++) {
Matcher matcher = PATTERNS[i].matcher(result)
result = matcher.replaceAll(CARACTERES_SEM_ACENTO[i])
}
return result
}
static encode = {str ->
str = replaceSpecial(str.toString().toLowerCase())
return str.replaceAll("\\W", "-")
}
}
To use it in your Grails project, save it in grails-app/utils/com/deluan/grails/codecs
folder as PermalinkCodec.groovy
.
Please read the (excelent) Grails manual for more info on how to use codecs.
]]>