External configuration files allow you to make these changes without having to redeploy the war file.

Looking at the top of Config.groovy (this is from Grails 1.2.0), you will see that following fragment that has been commented out.

1
2
3
4
5
6
7

// locations to search for config files that get merged into the main config
// config files can either be Java properties files or ConfigSlurper scripts
 
// grails.config.locations = [ "classpath:${appName}-config.properties",
//                             "classpath:${appName}-config.groovy",
//                             "file:${userHome}/.grails/${appName}-config.properties",
//                             "file:${userHome}/.grails/${appName}-config.groovy"]

The example provided shows that configuration data can be supplied in the classpath or in the file system and can be a Groovy file or a Java properties file. I chose to use a Groovy file in the file system, so my declaration looks like the following:

1

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

Note: This was for testing. For production use, I would use a directory like: /grails/app-config or use the classpath location.

To test the idea, I commented out all the logging configuration in Config.groovy. My test application name is st3, so my st3-config.groovy file contains the following:

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

 
// log4j configuration
log4j = {
    appenders {
        rollingFile name:'rollingFile', maxFileSize:102400, maxBackupIndex: 5, file:'/temp/logs/st3.log',
                    layout:pattern(conversionPattern:'%d %-5p %c{2} %x - %m%n')
        console name:'stdout', layout:pattern(conversionPattern: '%c{2} %m%n')
    }
 
    root {
        error 'stdout', 'rollingFile'
    }
 
    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
               'org.springframework',
               'org.hibernate',
               'net.sf.ehcache.hibernate',
	       'org.apache'
 
    warn   'org.mortbay.log'
 
    debug  'grails.app'
 
}
 
// st3 properties
st3.importDb.url='jdbc:mysql://localhost/jsfsc'

This configuration changes the default “layout” for the console logging and adds a rolling file appender as well. The last line of the file defines a new configuration property called st3.importDb.url to demonstration how you could handle application properties.

You can access the configuration in your controllers through the grailsApplication property that gets injected as follows:

1

println grailsApplication.config.st3.importDb.url

If you want to access configuration data in a service, you can do so as follows:

1
2
3
4
5
6
7
8
9
10
11
12

import org.codehaus.groovy.grails.commons.*
 
class DataLoaderService {
    def config = ConfigurationHolder.config
 
    boolean transactional = true
 
    def loadData() {
        log.debug 'loadData called debug'
        log.debug "st3.importDb.url = ${config.st3.importDb.url}"
    }
}

Now you have the flexibility to configure your application the way to want.

Going beyond that, SchemaSpy uses GraphViz to generate a diagrams from the schema. Below is a screen shot. A larger version can be found here.

SchemaSpy Sample Output

SchemaSpy is a command line tool. If you prefer to use a GUI, check out SchemaSpyGUI.

I have not experimented with the various options and customizing the output using meta data described in an XML file. This would be useful to add comments to the documentation or identify columns as foreign keys where that information is not captured in the schema’s meta data.

With the default options, the tool gave me exactly what I was looking for.

Step 1 – Backup your current configuration, just in case
Select the Administration tab and then the Config Management link. Click the Backup button to download your current configuration. These can be used to restore the router to the current configuration if you need to on this same page.

Step 2 – Reset the router to the factory defaults
You may want to skip this. I did just to make sure some odd setting I changed would not cause problems later. Press and hold the reset button for at least 5 seconds.

Step 3 – Disable the DHCP server
Assuming your new router/firewall acts as a DHCP server, you need to disable the WRT54G DHCP server. Go to the Setup tab and make sure Disable is selected beside DHCP Server.

While you are on this page, you might want to double check the Time Zone is correct.

Click Save Changes.

Step 4 – Change the operation mode
Click the Advanced Routing link on the Setup page. Make sure Router is selected beside Operating Mode.

Click Save Changes.

Step 5 – Connect the WRT54G to your network
Connect a cable from you router/firewall to a LAN port on the WRT54G. Do not connect the cable to the Internet port. That will not work.

That should do it! You will want to change the wireless settings to make it more secure. The manual will help you accomplish that.

groovy.lang.MissingMethodException: No signature of method: static Thing.count() is applicable ...

Thing is a Grails Domain class and Grails adds the count method dynamically. So, what is the problem? It turns out to be just a matter of timing. The initMethod of our Spring created and initialized Java class is getting called prior all of the dynamic methods getting added to our Domain classes.

The fix is easy, once you understand what is going on. The Grails team has a hook that you can take advantage of. You will find examples of it’s use in the area of creating and saving instances of Domain objects on various web sites. The hook is the init method in BootStrap.groovy, which will be found in /grails-app/conf.

Below is an example of the default BootStrap class.

1
2
3
4
5
6
7

class BootStrap {
 
     def init = { servletContext ->
     }
     def destroy = {
     }
}

The init method of BootStrap will be called when Grails has completely initialized your application and all of the dynamic methods are available. This is the safe place to invoke the initMethod of your Spring created class. Below is a solution to the problem, which uses Grails auto-wire to get a reference to the Spring created class.

1
2
3
4
5
6
7
8
9

class BootStrap {
    def example
 
     def init = { servletContext ->
         example.init()
     }
     def destroy = {
     }
}

As indicated in the title of this post, this work was done with the recently released Grails 1.1.

The Interface

I created an Interface that would expose methods in the service for the Java class we will create. This Interface is created in the src/java directory in your grails project.

1
2
3
4
5
6
7
8
9

package com.comitservices.stuff;
 
/**
 * Interface for services.
 * @author mbrown
 */
public interface IService {
    String getName();
}

The Service

Any service class that could be called from the Java class we will create with Spring will need to implement this Interface.

1
2
3
4
5
6
7
8
9
10

import com.comitservices.stuff.IService
 
class ThingService implements IService {
 
    boolean transactional = true
 
    public String getName() {
        this.class.name
    }
}

The Java Class

Here is the Java class that will be created and initialized by Spring and call a service class.

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

package com.comitservices.stuff;
 
/**
 * Example Spring configured class.
 * @author mbrown
 */
public class Example {
    private IService service;
    private String xx;
 
    public void init() {
        System.out.println("Value of xx: " + xx);
        System.out.println("Service name: " + service.getName());
    }
 
    /**
     * @return the service
     */
    public IService getService() {
        return service;
    }
 
    /**
     * @param service the service to set
     */
    public void setService(IService service) {
        this.service = service;
    }
 
    /**
     * @return the xx
     */
    public String getXx() {
        return xx;
    }
 
    /**
     * @param xx the xx to set
     */
    public void setXx(String xx) {
        this.xx = xx;
    }
 
}

The Spring Initialization Part

When you create an grails application, an empty spring configuration file is created in grails-app/conf/spring named resources.groovy. You will notice that is not an XML file, but a Groovy file instead. The syntax for this file will use the Spring DSL.

Here is an populated resources.groovy file for initializing the Java class above. A bean named example will be created, the properties xx and service will be initialized and the specified initialization method will be called.

1
2
3
4
5
6
7

beans = {
    example(com.comitservices.stuff.Example) { bean ->
        service = ref("thingService")
        xx = "set by Spring"
        bean.initMethod = 'init'
    }
}

Running the Application

You may have noticed that the init method in the Java class simply prints out information to System.out. The following is copied from the output when running the grails application. You can see the println results immediately after “Running Grails application”.

Running script /home/mbrown/grails-1.1/scripts/RunApp.groovy
Environment set to development
  [groovyc] Compiling 2 source files to /home/mbrown/.grails/1.1/projects/g1.1.test/classes
     [copy] Copied 1 empty directory to 1 empty directory under /home/mbrown/.grails/1.1/projects/g1.1.test/resources
Running Grails application..
Value of xx: set by Spring
Service name: ThingService
Server running. Browse to http://localhost:8080/g1.1.test