If you are working on a Groovy script with @Grab, you will sometimes get download failures for dependencies. Such as the following:

1
General error during conversion: Error grabbing Grapes -- [download failed: com.google.guava#guava;16.0!guava.jar(bundle), download failed: org.javassist#javassist;3.18.1-GA!javassist.jar(bundle)]

This issues may have nothing to do with the actual dependency but an issue in your local m2 cache. The quick answer is to just delete ~/.groovy/grapes and ~/.m2/repository. But doing this will force you to re-download dependencies.

To only delete the cache for items giving you an issue you just need to delete the correct directories in both m2 and grapes cache. So for our Guava example you would do the following:

1
2
rm -r ~/.groovy/grapes/com.google.guava
rm -r ~/.m2/repository/com/google/guava

After that you should be able to run the groovy script normally.

New Relic with Grails by default will trace most web transactions through the controller but will not trace down into services. While most true work of a request belongs in services or libraries the default tracing leaves something to be desired.

This is easily fixed by adding New Relic annotations to services and libraries.

BuildConfig.groovy Changes

1
2
3
4
dependencies {
  compile 'com.newrelic.agent.java:newrelic-api:3.4.2'

}

Service Changes

1
2
3
4
5
6
7
8
import com.newrelic.api.agent.Trace

class SubscriptionService {

  @Trace
  def save(Subscription subscription) {
    //Work Here
  }

At this point your code is ready to give more detailed transactions, but the agent on the server must also be configured to accept custom tracing. The config option for this is not available from the web so you must update the newrelic.yml file. Set enable_custom_tracing to true.

1
2
  #enable_custom_tracing is used to allow @Trace on methods
  enable_custom_tracing: true

Now you will get any custom tracing added to your application as well as custom tracing from libraries.

If you are running grails 2.3.1 and see the following sequence pop up before you get some odd test failures.

1
2
3
4
5
6
7
$ grails clean
| Application cleaned.

$ grails test-app
| Environment set to test.....
| Warning No config found for the application.
| Warning DataSource.groovy not found, assuming dataSource bean is configured by Spring

Start using package in between and the problem will go away.

1
2
3
4
5
6
7
8
9
10
11
12
13
$ grails clean
| Application cleaned.
$ grails package
| Compiling 10 source files
| Compiling 12 source files.....

$ grails test-app
| Environment set to test.....
| Server running. Browse to http://localhost:8080/api
| Running 6 cucumber tests...
| Completed 6 cucumber tests, 0 failed in 0m 3s
| Server stopped
| Tests PASSED

Using the JMS 1.2 plugin with Grails 2.3.0.RC1 was producing a number of odd results. Mostly with missing JMS files it turns out that the new spring version didn’t have the needed spring jms included. Just add the following to BuildConfig.groovy

1
2
3
4
dependencies {
  compile 'org.springframework:spring-jms:3.2.4.RELEASE'
  ...
}

Using the Grails Spring Security Core Plugin I found the need to customize the UserDetailsService and use a Grails service. (Part of the roles logic depended on an external API that we already had a service for.) This was easy to accomplish by subclassing the UserDetailsService class I wanted as a base in my case it was actually the SpringSamlUserDetailsService class because I was using the SAML plugin but normally you would subclass GormUserDetailsService. A great starting example is given in the documentation here.

The difference in my case was the need to use the Grails service, I went with providing the service in the resources.groovy file. Below is the example file of what I used.

My resources.groovy

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import com.example.saml.CustomUserDetailsService
import org.codehaus.groovy.grails.plugins.springsecurity.SpringSecurityUtils

beans = {
      userDetailsService(CustomUserDetailsService) {
       grailsApplication = ref('grailsApplication')
       myService = ref('myService')  //Here we give the reference to the service we want available.
       authorityClassName = SpringSecurityUtils.securityConfig.authority.className
       authorityJoinClassName = SpringSecurityUtils.securityConfig.userLookup.authorityJoinClassName
       authorityNameField = SpringSecurityUtils.securityConfig.authority.nameField
       samlAutoCreateActive = SpringSecurityUtils.securityConfig.saml.autoCreate.active
       samlAutoAssignAuthorities = SpringSecurityUtils.securityConfig.saml.autoCreate.assignAuthorities as Boolean
       samlAutoCreateKey = SpringSecurityUtils.securityConfig.saml.autoCreate.key as String
       samlUserAttributeMappings = SpringSecurityUtils.securityConfig.saml.userAttributeMappings
       samlUserGroupAttribute = SpringSecurityUtils.securityConfig.saml.userGroupAttribute as String
       samlUserGroupToRoleMapping = SpringSecurityUtils.securityConfig.saml.userGroupToRoleMapping
       userDomainClassName = SpringSecurityUtils.securityConfig.userLookup.userDomainClassName
       authoritiesPropertyName = SpringSecurityUtils.securityConfig.userLookup.authoritiesPropertyName
   }
}

Snip from CustomUserDetailsService.groovy

1
2
3
4
class CustomUserDetailsService extends SpringSamlUserDetailsService {
  def myService
...
}

Getting, SAML message intended destination endpoint did not match recipient endpoint, errors mean the server itself dosen’t match the urls being given in the SAML messages.

We are using the Grails Spring Security SAML Plugin on a Tomcat server. In my case this was happening because we were doing SSL offloading on the load balancer. So if you look at the logs there should be an error log with the intended destination and the recipient endpoint.

In my case the first error was only different by http vs https. The fix for that was simply to apply the scheme attribute to that connector in tomcat. At which point everything was matching except that the port was now being added as 80 in my endpoint and that wasn’t in the intended endpoint. The fix for this was just to add the proxyPort to the connector as well.

So to fully support the OpenSAML on tomcat with SSL offloading I configured the connector as seen below. Take note of the scheme and proxyPort being set.

1
2
3
4
5
6
<Connector port="8080" protocol="HTTP/1.1"
               enableLookups="false"
               maxThreads="250"
               connectionTimeout="20000"
               scheme="https"
               proxyPort="443"/>

While working with Grails and the Spring Security plugin, the current spring security filter chain is available in the springSecurityFilterChain bean. It is very easy with that to show what the current chain looks like so you can work through filter chain issues. I used the following code in the Grails Console plugin to get the bean:

1
def filterChain = ctx.getBean('springSecurityFilterChain')

Also if you want to poke around the other beans available this is a great post to check out: Spring Beans from the Grails Console .

I’ve been working with the DataStax Enterprise 2.01 install for a bit now and it was working great until one day I was no longer able to get any queries to work using the cqlsh I was just getting the error that one or more nodes was unavailable. I tried restarting and still nothing would work I got a few errors in the logs (shown below).

I was able to quickly fix the error by removing my data directory and starting fresh as this is just my development environment that works great for me. You can find your data directory in the cassandra.yaml file ($DSE_HOME/resources/cassandra/conf/cassandra.yaml), look for the data_file_directories entry. Mine was set to /var/lib/cassandra/data so I just ran the following and started cassandra fresh and everything is back to working order.

1
rm -r /var/lib/cassandra/data
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
INFO [JOB-TRACKER-INIT] 2012-12-28 10:32:32,515 JobTracker.java (line 2427) problem cleaning system directory: cfs:/tmp/hadoop-jeffbeck/mapred/system
java.io.IOException: UnavailableException()
  at com.datastax.bdp.hadoop.cfs.CassandraFileSystemThriftStore.listSubPaths(CassandraFileSystemThriftStore.java:1137)
  at com.datastax.bdp.hadoop.cfs.CassandraFileSystem.listStatus(CassandraFileSystem.java:192)
  at org.apache.hadoop.mapred.JobTracker.<init>(JobTracker.java:2392)
  at org.apache.hadoop.mapred.JobTracker.<init>(JobTracker.java:2195)
  at org.apache.hadoop.mapred.JobTracker.<init>(JobTracker.java:2189)
  at org.apache.hadoop.mapred.JobTracker.startTracker(JobTracker.java:303)
  at org.apache.hadoop.mapred.JobTracker.startTracker(JobTracker.java:294)
  at org.apache.hadoop.mapred.HadoopTrackerPlugin$1.run(HadoopTrackerPlugin.java:230)
  at java.lang.Thread.run(Thread.java:680)
Caused by: UnavailableException()
  at org.apache.cassandra.service.ReadCallback.assureSufficientLiveNodes(ReadCallback.java:212)
  at org.apache.cassandra.service.StorageProxy.scan(StorageProxy.java:1083)
  at org.apache.cassandra.thrift.CassandraServer.get_indexed_slices(CassandraServer.java:746)
  at com.datastax.bdp.hadoop.cfs.CassandraFileSystemThriftStore.listSubPaths(CassandraFileSystemThriftStore.java:1120)
  ... 8 more

The grails release plugin is great for publishing plugins to grails central but it will also publish a plugin to a maven repo. You simple need to configure the new maven repo inside build config. But if you want to release snapshots to an internal maven but not have that config checked in publicly that is a bit more tricky. With a quick bit of code added to BuildConfig.groovy we can have it pull in the config from a file we can choose to not checkin. Now with our public code we don’t need to expose our internal login info. See the file changes below for an example.

Add this to BuildConfig.groovy:

1
2
3
4
5
6
7
8
9
10
11
def mavenConfigFile = new File("${basedir}/grails-app/conf/mavenInfo.groovy")
if (mavenConfigFile.exists()) {
  def slurpedMavenInfo = new ConfigSlurper().parse(mavenConfigFile.toURL())
  slurpedMavenInfo.grails.project.repos.each {k, v ->
      println "Adding maven info for repo $k"
      grails.project.repos."$k" = v
  }
}
else {
  println "No mavenInfo file found."
}

Then you can create a file called mavenInfo.groovy:

1
2
3
grails.project.repos.internalSnap.url = 'http://internal.com:8080/nexus/content/repositories/internal-snapshots/'
grails.project.repos.internalSnap.username = 'fakeUser'
grails.project.repos.internalSnap.password = 'fakePass123'

Grab the gist.

I am using a simple redirect after a user logs in so they can get to the page they were heading too the URLs were ending up with %2F in the url which caused a 404 error. The problem wasn’t actually in Grails at all but in the mod_rewrite rule being used to force HTTPS connection the rule was set up to end with [L,R] when to correctly deal with the url encoding we were already doing it needed to be [NE,L,R]

Reference: http://www.webmasterworld.com/apache/3279075.htm