Archive

Archive for the ‘Grails Plugin’ Category

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"
grails.project.work.dir = "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/10.109.112.186
Loading Grails 2.4.4
|Configuring classpath
.
|Environment set to development
......
|Installing zip release-3.0.1.zip...
...
|Installed plugin release-3.0.1
.............
|Installing zip rest-client-builder-1.0.3.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

grails-work

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!

Advertisements
Categories: Grails, Grails Plugin Tags:

another silly gotcha grails 2.4 and plugin development with integration testing

November 15, 2014 Leave a comment

just wasted an hour getting the to the bottom of this. Hope this saves you some of that.

i just created a new Grails plugin project using grails 2.4.4 using GGTS. Plugin project gets created fine.

I created a couple of domain classes and tried to run an integration test.

hah first point. The grails documentation hasn’t caught up with what the code does. The documentation for unit tests still refers to extending the GroovyTestCase. However this is no longer what the code generator assumes you should do. Generating a integration test and you see the class now extends

import grails.test.spock.IntegrationSpec
..
class xxxSpec extends IntegrationSpec {

    def setup() {
    }

    def cleanup() {
    }

    void "test something"() { 
    }
}

slightly annoying point is that spoc which is the default test runner assumes that you have the
when :, then:, expect: or similar blocks to be happy and the default template generation doesn’t do this for you. as a Newbie this can catch you out if you try and run tests.

however the key waste of time today was with a new plugin project. By default the plugin project doesn’t load the hibernate plugin in buildConfig.groovy. When you run your integration test it throws a weird error along the lines of


java.lang.IllegalStateException: Method on class [Domain class] was used outside of a Grails application

which throws you completely. What says you? of course i’m running grails that’s integration tests do for you. The answer is that missing hibernate plugin which causes the problem. I eventually found this on stackoverflow .

add the runtime plugin for hibernate in buildConfig and off you go

there are it appears other issues when using functional testing – but i’ve not got that far. part of the resolution to that requires you to include another plugin : remote-control plugin. I’ve included the link here as i’m bound to need it later

There is another bug also hibernate4 4.3.6.1 doesn’t inject the dateCreated, lastUpdated Dates automatically. you have to roll back to 4.3.5.5 and then it works as expected in integration tests

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(FactoryFinder.java:1135)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:379)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:350)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1280)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1193)

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

%d bloggers like this: