JDriven Blog

Ratpacked: Easy URI Creation With HttpUrlBUillder

Posted on by  
Hubert Klein Ikkink

When we need to create a URI object in Ratpack we can use the HttpUrlBuilder class. We use several methods to build up a complete URI object in an easy way. This is very useful when we for example use Ratpack’s HttpClient object and we need to pass an URI to do a request.

In the following example specification we see several usages of the HttpUrlBuilder class:

Continue reading →

Gradle Goodness: Skip Task When Input Empty Using @SkipWhenEmpty Annotation

Posted on by  
Hubert Klein Ikkink

Gradle has excellent incremental build support. This means that Gradle can determine if a task needs to be executed based on the input and output of that task. If for example nothing changed in one of the input and output files, then the task can be skipped. We can add incremental build support for our custom tasks by defining the input and output of the task. We can also define that a task can be skipped when a collection of files or a directory that is the input of the task are empty or not exists. Gradle offers the @SkipWhenEmpty annotation we can apply on the input of our task.

In the next example we have a task DisplayTask that prints the contents of files in a directory. We want to skip the task when the directory is empty.

Continue reading →

Grails Goodness: Custom JSON and Markup Views For Default REST Resources

Posted on by  
Hubert Klein Ikkink

In Grails we can use the @Resource annotation to make a domain class a REST resource. The annotation adds a controller as URL endpoint for the domain class. Values for the domain class properties are rendered with a default renderer. We can use JSON and markup views to customize the rendering of the domain class annotated with a @Resource annotation. First we must make sure we include views plugin in our build configuration. Then we must create a directory in the grails-app/views directory with the same name as our domain class name. Inside the directory we can add JSON and markup views with names that correspond with the controller actions. For example a file index.gson or index.gml for the index action. We can also create a template view that is automatically used for a resource instance by adding a view with the name of the domain class prefixed with an underscore (_).

In the next example application we create a custom view for the Book domain class that is annotated with the @Resource annotation:

Continue reading →

Grails Goodness: Using Domain Classes Without Persistence

Posted on by  
Hubert Klein Ikkink

Normally when we create a domain class in Grails we rely on GORM for all the persistence logic. But we can use the static property mapWith with the value none to instruct Grails the domain class is not persisted. This can be useful for example if we want to use a RestfulController for a resource and use the default data binding support in the RestfulController. The resource must be a domain class to make it work, but we might have a custom persistence implementation that is not GORM. By using the mapWith property we can still have benefits from the RestfulController and implement our own persistence mechanism.

In the following example we have a simple Book resource. We define it as a domain class, but tell Grails the persistence should not be handled by GORM:

Continue reading →

Release NPM package with git-flow

Posted on by  
Willem Cheizoo

Having an NPM package in an enterprise environment and wanting to release that package using the git-flow model? Then using the [node-generate-release](https://ift.tt/28QYo7d) can be very helpful. This blog shows how to execute an integrated git flow release from your NPM package, even if your master and develop branches are protected.

Let’s assume we have all changes in the develop branch and we would like to create a release with all the current changes in develop. With the git-flow release the result will be that all changes will be merged into master and a tag for the release version is created with correct version. Before we can finish the release the correct version in NPM package.json needs to be set. This can all be nicely done with node-generate-release plugin.

Continue reading →

Groovy Goodness: Using The Call Operator ()

Posted on by  
Hubert Klein Ikkink

In Groovy we can add a method named call to a class and then invoke the method without using the name call. We would simply just type the parentheses and optional arguments on an object instance. Groovy calls this the call operator: (). This can be especially useful in for example a DSL written with Groovy. We can add multiple call methods to our class each with different arguments. The correct method is invoked at runtime based on the arguments.

In the following example we have User class with three call method implementations. Next we see how we invoke the call methods, but without typing the method name and just use the parenthesis and arguments:

Continue reading →

Groovy Goodness: Creating Root JSON Array With JsonBuilder

Posted on by  
Hubert Klein Ikkink

To create JSON output with Groovy is easy using JsonBuilder and StreamingJsonBuilder. In the samples mentioned in the links we create a JSON object with a key and values. But what if we want to create JSON with a root JSON array using JsonBuilder or StreamingJsonBuilder? It turns out to be very simple by passing a list of values using the constructor or using the implicit method call.

In the following example we use JsonBuilder to create a root JSON array:

Continue reading →

Gradle Goodness: Check Operating System In Build Scripts

Posted on by  
Hubert Klein Ikkink

Sometimes we want to check which operating system is used in our build script. For example we have tasks that need to run if the operating system is Windows and not for other operating systems. Gradle has an internal class org.gradle.nativeplatform.platform.internal.DefaultOperatingSystem, but we should not use this class in our build scripts. The class is used internally by Gradle and can change without warning. If we would depend on this class and it changes we break our build scripts. But we can use a class from Ant that is already in Gradle’s class path: org.apache.tools.ant.taskdefs.condition.Os. The class has several methods and constants to check the operating system name, version and architecture. The values are based on the Java system properties os.name, os.version and os.arch.

In the following example build script we use import static to include the Os class, so we can directly invoke the methods and refer to the constants in the Os class. We add some tasks that have a condition check with onlyIf so the task only runs when the condition in the closure is true. The task osInfo simply shows values from the Os class:

Continue reading →

Forcing HTTPS with an .htaccess file on Heroku

Posted on by  
Deniz Turan

Normally, forcing HTTPS with an .htaccess file is pretty straightforward, and not too difficult. You simply add the following to the top of your .htaccess file:

You have a RewriteCond that checks whether HTTPS is on or off, and after that you create a RewriteRule that redirects the user to the same host/URI, but with HTTPS instead of HTTP. The L flag prevents any other rule in the .htaccess file from being applied, and the R flag is a redirect (the 301 status code is for SEO optimization).

See this for documentation on rewrite module for Apache server.

So when you try this on an application hosted on Heroku (I’m using a Cedar stack), this won’t work because there will be a infinite redirect loop.

The reason for that is that our rewrite condition is always failing. This is because Heroku has a sweet load balancer between the client and the application. So the client connects with HTTP (or HTTPS) to the load balancer, not the application. The load balancer then connects to our application using TCP(as described here), causing the HTTPS variable to be set to off.

To resolve the issue, Heroku uses the header X-Forwarded-Proto to pass on the protocol that was used by the client.

X-Forwarded-Proto is a non-standard header which is commonly used by other services, like Amazon Web Services.

With that knowledge, all we have to do is rewrite the RewriteCond to the following:

Now it should work. Please note that this won’t work on every server unless you set this header. If you want to make sure it works everywhere (for example your dev server), simply add both rewrite conditions:

Continue reading →

shadow-left