Posts Tagged ‘Grails’

Keep things where you can see stuff for grails projects

January 26, 2015 Leave a comment

Been having issues with a plugin project i’ve been trying to mend. This has led to exploration round plugins, gant scripts etc.

The latest one has been relating to gant script caching – when i added some script and got and error. So i removed the lines – and the cached version of the script with the error continues to being run. Not sure why. However short term quickfix is delete the script cache between calls

however on the way to finding the script cache and clearing it out – i’ve trod where others have been. One of the things that is a good thing to do is to update your conf/buildConfig.grooy file up at the top and add this little line

grails.project.class.dir = "target/classes"
grails.project.test.class.dir = "target/test-classes"
grails.project.test.reports.dir = "target/test-reports" = "target/work" //add this line :where default work is stored

by default grails stores all the project work in .grails/.. This is not immediately obvious to newbies. by setting the work.dir inside your project – its easy to go looking and understand what the framework might be doing behind the scenes.

having the added the line, in GGTS select your project, right click and do Grails tools/Refresh dependencies

when you do that you’ll notice that the plugins are ‘re fetched’ and added in this case to the /target/work directory

Starting process on BTP055237/
Loading Grails 2.4.4
|Configuring classpath
|Environment set to development
|Installing zip
|Installed plugin release-3.0.1
|Installing zip
|Installed plugin rest-client-builder-1.0.3
|Compiling 13 source files
|Compiling 4 source files

this creates the work directory in your project like this


when you run a script the compiled copy goes into the scriptCache as shown. However there is is an issue in the current grails2.4.4 where if you update the script after first running it, the script cache doesn’t update to the later groovy script you just saved. The tactical way round this (brute force) is to call the clean-all script which releases the GGTS lock on the closure, cleans the cache and you can then re-run the script which will recompile and recache. Bit painful but seems to work, without having to restart GGTS each time!

Categories: Grails, Grails Plugin Tags:

new Grails App : Annoying gripe and time waster : create-drop with default h2 db

September 23, 2014 Leave a comment

fell over this is with latest grails builds GGTS 3.6.1 / grails 2.4.2

if your new to grails what you want to do is quickly add a domain object and try and run some tests quickly etc

instead you get a silly error like this

HHH000389: Unsuccessful: alter table … drop constraint …

and it fails to start. This is frankly annoying and ought to be handled properly – but isn’t fixed yet.

The problem is with in memory DB use and using the create-drop default for hibernate with the H2 drivers. it gets confused as the db doesn’t exist and you can’t drop whats not there .

the easy fix is to override the default H2 dialect. create a file like this in your src/groovy (or java) folders

package com.softwood;

import org.hibernate.dialect.H2Dialect;

 * Workaround.
 * @see
public class ImprovedH2Dialect extends H2Dialect {
    public String getDropSequenceString(String sequenceName) {
        // Adding the "if exists" clause to avoid warnings
        return "drop sequence if exists " + sequenceName;

    public boolean dropConstraints() {
        // We don't need to drop constraints before dropping tables, that just
        // leads to error messages about missing tables when we don't have a
        // schema in the database
        return false;

then in your conf/DataSource.groovy add this line at the top of the file

dataSource.dialect = com.softwood.dialects.ImprovedH2Dialect

then re-run the grails run-app and the problem should disappear

this never used to happen so they ought to provide a fix for it as its very easy to put off new entrants from getting started

alternatively you can set the dbCreate = “update” which avoids the drop call on the empty in memory db

pretty annoying and hope this sames someone some heartache wondering what to do next

Categories: Grails Tags: , ,

Proxy Management for Gradle, Eclipse and Grails…

March 19, 2014 1 comment

This is an ever thorny subject and scope for much pain for users including myself

So thought i’d catalog the best way to set this up when working behind a firewall

starting with

Best way for gradle is to add file into into the root of your project or into into USER_HOME/.gradle (user wide config)

basic attributes you may need to set are

then refresh the dependencies (say from within your eclipse build with Gradle project support enabled)

Grails Projects

For Grails projects (v2 onwards) you can creat a ProxySettings.groovy file in the “${userHome}/.grails/scripts/ProxyConfig.groovy” directory and refresh the grails dependencies (note: this is global to all projects) where the file format is like this

MyProxy=['http.proxyHost':'xx.xx.xx.xx', 'http.proxyPort':'8080', 'http.proxyUser':'', 'http.proxyPassword':'', 'http.nonProxyHosts':'my_maven_server']

alternatively you are supposed to be able run the following commands on grails

grails add-proxy proxyConf –host=proxy-server –port=4300
–username=guest –password=guest
grails set-proxy proxyConf

though i’m not certain that i have had this work in call cases but adding the file seems to.

lastly if that doesn’t work – you can try and edit your projects /conf/BuildConfig.groovy and add the following to that file[
   "http.proxyHost": "",
    "http.proxyPort": "8080",
    "http.proxyUserName": "myUser",
    "http.proxyPassword": "myPass"

Eclipse itself

best i have found Eclipse itself is to add the proxy in the eclipse.ini file (or GGTS.ini etc ) with your eclipse build

you need to be careful – there can be no spaces round the definition else Eclipse doesn’t seem to read it correctly

You need to specify the following options below the -vmargs option in the .ini file, each on a separate line and spare whitespace at the end etc

and if this doesnt work you can try adding

and try again.

Good luck

Basic Gorm Relationship Mappings

February 9, 2014 Leave a comment

I’ve placed a word document with UML pictures to show what happens on the database for various relationship mappings. Its not always obvious what you get and when in the configuration so i’ve tried to show in summary form what happens when you drive the model

Gorm Basic Model Mappings

Hope this makes sense for others

Categories: Grails Tags: , ,

How to get Grails log output in unit testing

February 6, 2014 Leave a comment

Spent some time struggling with getting grails to produce output from logging when running unit and integration tests

read the documentation and tried various stuff to no avail. Then i spotted something silly i’d done (i had def setup () and def teardown () methods – which don’t get called. They needed to be void setUp(), and void tearDown())

having fixed this my code started to get called.

grails injects a log property into unit tests which is of type java.util.logging.Logger. In the GGTS console this prints out in red.

if you don’t want the injected log you can get one directly using one of the logger factories (either apache, or sl4j) like this

package com.softwood

import grails.test.mixin.*
import grails.test.mixin.domain.DomainClassUnitTestMixin

import org.neo4j.graphdb.GraphDatabaseService

import org.slf4j.Logger
import org.slf4j.LoggerFactory
import org.apache.commons.logging.LogFactory

class DomainTests {
	GraphDatabaseService gdb
	static Logger sllog = LoggerFactory.getLogger(DomainTests)
	def alog = LogFactory.getLog(getClass())
	void setUp () { "java util: hello William : " + log.class 
		assert sllog.isInfoEnabled() "sl4j: getting gdb bean : " + sllog.class "apache: getting gdb bean : " + alog.class

you’ll notice the assert on one of the loggers – this is checking that Info logging is enabled.

you control that by ensuring that the log4j section in grails-app/conf/config.groovy is set correctly. This is described in section 4.1.2 of the grails users guide.

you have to explicitly set the level in order to see the output. The logger will print from the level and any above. My default configuration from the project create didn’t include any “Info” logging so i added the last line – info ‘com.softwood’

if you remove this – then the assert previously noted will fail

I didn’t need to uncomment out the root section – though you can, it sets the default behavior for the root logger that the others inherit

// log4j configuration
log4j = {
    // Example of changing the log pattern for the default console appender:
    appenders {
        console name:'stdout', layout:pattern(conversionPattern: '%c{2} %m%n')
	//set default root logger behaviour for the system - use info and send to console appender
	root {
		error    'stdout'
		additivity = true
	} */

    error  'org.codehaus.groovy.grails.web.servlet',        // controllers
           'org.codehaus.groovy.grails.web.pages',          // GSP
           'org.codehaus.groovy.grails.web.sitemesh',       // layouts
           'org.codehaus.groovy.grails.web.mapping.filter', // URL mapping
           'org.codehaus.groovy.grails.web.mapping',        // URL mapping
           'org.codehaus.groovy.grails.commons',            // core / classloading
           'org.codehaus.groovy.grails.plugins',            // plugins
           'org.codehaus.groovy.grails.orm.hibernate',      // hibernate integration
	info   'com.softwood' 

having done this when you now run your test – and i didn’t need to -echoOut to the test-app -unit , you’ll see your output print to the console

the explicit loggers generate black text output – and have slightly less decoration than the default injected log

|Configuring classpath
|Environment set to test
|Compiling 1 source files
|Running 1 unit test...
|Running 1 unit test... 1 of 1Feb 06, 2014 10:49:24 PM java_util_logging_Logger$info call
INFO: hello William : class java.util.logging.Logger

softwood.DomainTests getting gdb bean : class org.slf4j.impl.GrailsLog4jLoggerAdapter
softwood.DomainTests a: getting gdb bean : class org.apache.commons.logging.impl.SLF4JLog
|Completed 1 unit test, 0 failed in 0m 3s
|Tests PASSED - view reports in C:\Users\802518659\Documents\temp (not backed up)\grails 3.3 workspace\TestNeo4jGrails235\target\test-reports

so now we are back on track and you can see some output when you run your unit tests – not just whether the asserts pass or fail quietly

note: when you do an integration test the log that’s injected by Grials by default is now of type class org.apache.commons.logging.impl.SLF4JLog

also integration tests don’t use the unit test mixins so you just extend your test class from GroovyTestCase.

good testing …

Eureka moment – “could not find Factory: javax.faces.context.FacesContextFactory” and embedded tomcat and grails

August 23, 2013 Leave a comment

Whoa – major breakthrough

I have been to build a grails project and get it to use JSF and have kept running into problems like this when building grails plugin projects and trying to publish to the embedded tomcat – which I have tried and failed for about a year to get to the bottom of without success

INFO: Initializing Spring root WebApplicationContext
Aug 23, 2013 11:53:20 AM javax.faces.FactoryFinder$FactoryManager copyInjectionProviderFromFacesContext
SEVERE: Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?
Aug 23, 2013 11:53:20 AM javax.faces.FactoryFinder$FactoryManager getFactory
SEVERE: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory. Attempting to find backup.
Aug 23, 2013 11:53:20 AM org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
java.lang.IllegalStateException: Could not find backup for factory javax.faces.context.FacesContextFactory.
at javax.faces.FactoryFinder$FactoryManager.getFactory(
at javax.faces.FactoryFinder.getFactory(
at javax.faces.webapp.FacesServlet.init(
at org.apache.catalina.core.StandardWrapper.initServlet(
at org.apache.catalina.core.StandardWrapper.loadServlet(

Then I was having the problem again this morning – must fourth attempt at getting past this little hurdle when I ran into the following item hidden away beneath google

about half way down there is a tiny comment about programmatically adding ctx.addListener(com.sun.faces.config.ConfigureListener.class); and the fact that the web.xml cant be found.

what it suggests you do is to add the following ctx.addContextInitParameter(“com.sun.faces.forceLoadConfiguration”, “true”);

so I tried the equivalent of this for the embedded comcat example in my plugin by adding this context param to the generated web.xml in the doWithXML closure in the plugin file

    def doWithWebDescriptor = { xml ->
        // TODO Implement additions to web.xml (optional), this event occurs before
		def contextParams = xml.'context-param'[0]
		contextParams + {
			'context-param' {
				'param-name' ('javax.faces.DEFAULT_SUFFIX')
				'param-value' ('.xhtml')
			'context-param' {
				'param-name' ('javax.faces.PROJECT_STAGE')
				'param-value' ('Development')
			'context-param' {
				'param-name' ('javax.faces.STATE_SAVING_METHOD')
				'param-value' ('client')
			'context-param' {
				'param-name' ('javax.faces.FACELETS_REFRESH_PERIOD')
				'param-value' ('1')

			'context-param' {
				'param-name' ('com.sun.faces.injectionProvider')
				//'param-value' ('com.sun.faces.vendor.WebContainerInjectionProvider')
				'param-value' ('com.softwood.SpringInjectionProvider')

			//use this for embedded tomcat when web.xml is defined programatically and its not in the project directly
			'context-param' {
				'param-name' ('com.sun.faces.forceLoadConfiguration')
				'param-value' ('true')

now when you run it the plugin starts and correctly loads the faces config context and your app works ! Holly cow batman

think i’m going to log this as a bug under the grails jira and see if someone cleverer than me can figure out the why’s – but heigh that now works in embedded tomcat – hoorah

Grails dependency management quick notes

April 13, 2012 Leave a comment

trying to get my head round how the grails dependency model works.  You can see the ivy resolution going on but its not quite clear where Grails packages the files you describe in BuildConfig.groovy

If you want a jar explicitly you can put in the /lib directory in your project.  But not sure whether this copied into /WEB-INF/lib.

copy of a post on web to be tidied up

  • build – dependency that is only needed by the build process
  • compile – dependency that is needed at both compile-time and runtime. This is the most common case
  • runtime – dependency that is needed to run the application, but not compile it e.g. JDBC implementation for specific database vendor. This would not typically be needed at compile-time because code depends only the JDBC API, rather than a specific implementation thereof – the runtime dependency would specicify the vendor impl jar

There are a couple of other dependency scopes:

  • test – dependency that is only needed by the tests
  • provided – dependency that is needed at compile-time but should not be packaged with the app (usually because it is provided by the container). An example is the Servlet API


Categories: Grails Tags:
%d bloggers like this: