register
other register

Thursday, November 03, 2011

Initialising in Grails Service

Attributes can be initialised from config in grails service by implementing the Spring InitializingBean interface. In the afterPropertiesSet method, set the attributes.

class SomeService implements InitializingBean {
def grailsApplication
private static String TOKEN

void afterPropertiesSet() {
TOKEN = grailsApplication.config.token
println this
}

def someMethod() {
println TOKEN
println this
}
}

In unit and integration test, the afterPropertiesSet method has to be called otherwise the TOKEN won't be set. But noticeably, in unit test, the instances printed out by 'println this' are different, although grails service by default is a singleton implementation; but in integration test, the instance from 'println this' is the same.

In unit test:

@Before
void setUp() {
service.afterPropertiesSet()
}
}

In integration test:

private static service

@BeforeClass
static void fixtureSetUp() {
service.afterPropertiesSet()
}

Saturday, October 22, 2011

Grails Service Singleton

Jeff Brown explained Grails singleton service in Nabble. Below is his description.

"If your service has an instance variable (that is state) and you don't want that state to be shared by multiple concurrent users of the service, then you don't want that service to be a singleton. If a service is a singleton then every user of that service is sharing the same copy of the service. If a service is request scoped then a new instance is created for every http request. If a service is sessions scoped then the service will be kept around and reused for the entire user session (each user session has their own copy). "

Thursday, October 20, 2011

Cannot get property 'config' on null object in Grails Integration Test

Class someService {

def grailsApplication

def someMethod() {

def attribute = grailsApplication.config.someAttribute
return attribute
}
}

When running integration test,

Class someServiceTests {

@Test
void testSomeMethod() {
def service = new SomeService()
def attribute = service.someMethod()
}
}

It will complain that:

"java.lang.NullPointerException: Cannot get property 'config' on null object"

The way around this is, in the integration test, add the following line:

service.grailsApplication = new DefaultGrailsApplication()

Thursday, September 15, 2011

Mock grailsApplication and config in Unit Test

grailsApplication can be injected in controller before 2.0.0, and it is still the case for 2.0.0

Before grails 2.0.0, you can only access your config in the service by calling ConfigurationHolder.config. But now with Grails 2.0.0, grailsApplication can be injected in service.

In unit test, we should do the following, so that the grailsApplication and config is mocked properly.

service.grailsApplication = [config.config]

controller.grailsApplication = [config: config]

Monday, September 12, 2011

Specify your own environment in Grails

environments {
  foo {
    settings = 'bar'
  }
}

To specify your environment:

grails -Dgrails.env=foo 


Wednesday, June 08, 2011

Proxy setting

If you are behind firewall, and your application need internet connection, then put the following code in your ~/.bash_profile

JAVA_OPTS="-Dhttp.proxyHost=yourProxyFileName -Dhttp.proxyPort=8080"
export JAVA_OPTS

Then refresh the console using:

. ~/.bash_profile

Thursday, February 10, 2011

Reload External Config File Dynamically

If the grails application's Config.groovy file is changed, the war file has to be regenerated to reflect the changes, and the war has to be redeployed onto the server. This process normally involves:

1. Generate the grails application war file.
2. Go to the tomcat manager console
3. Click "Undeploy" to remove the application's context.
4. Upload the newly generated war to the ${tomcat}/webapps directory

Adding an external config file (like the code below) in the Config.groovy file does allow not to re-generate the war file. It does allow you to define sensible configuration info (e.g. username, password, access allowed users, etc.) in an external file rather than packed within the generated war file.

grails.config.locations = [ "file:${userHome}/.grails/CoursePackApp/${appName}-config.groovy"]

However the web application doesn't load the changes in the external config file automatically, thus the application has to be stopped and re-started. This process normally involves:

1. Go to the tomcat manager console
2. Click "stop" to stop the application
3. Click "start" to start the application, so that the application can pick up the changes in the external config file.


To avoid the above hassle (i.e. regenerating the war file, restarting the application) every time we change the .

In the grails-app/conf/Config.groovy file, add:

grails.config.locations = ["file:${userHome}/.grails/YourPath/${appName}-config.groovy"]

On the server, create the external file at:

/userHome/.grails/YourPath/CoursePackApp-config.groovy

In a controller which is the entry point to the application (i.e. Login Controller), add the code below. Thus every time this controller action is accessed, the external config is re-loaded.

// Courtesy IntelliGrape http://bit.ly/aHZRjZ

// access external config file

def config = ConfigurationHolder.config
def locations = config.grails.config.locations

locations.each {
 String configFileName = it.split("file:")[1]
 config.merge(new ConfigSlurper().parse(new File(configFileName).text))
}