Deploying Grails app to tcServer in STS

[bkane]

Hi there,

I watched the excellent webinar a while back about profiling with Spring Insight for Grails apps in STS. The old version of STS could not deploy anything other than prod, so I waited until STS caught up and allowed deployment of other environments. 2.6.0M1 has this, so I thought I'd try it out again.

My grails app uses the default datasource configuration for the "development" environment:

environments {
	development {
		dataSource {
			pooled = true
			driverClassName = "org.hsqldb.jdbcDriver"
			username = "sa"
			password = ""
			dbCreate = "create-drop" // one of 'create', 'create-drop','update'
			url = "jdbc:hsqldb:mem:devDB"
		}
	}

But when I try to deploy and start it up in the local tcServer I get this exception:

Feb 27, 2011 10:52:35 PM org.apache.naming.NamingContext lookup
WARNING: Unexpected exception resolving reference
java.sql.SQLException
at org.apache.tomcat.jdbc.pool.PooledConnection.conne ctUsingDriver(PooledConnection.java:201)

...

Caused by: java.lang.NullPointerException
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at org.apache.tomcat.jdbc.pool.PooledConnection.conne ctUsingDriver(PooledConnection.java:195)
... 41 more

Any ideas what I'm doing wrong?

[Kris De Volder]

A few questions:

What version of Grails is being used? (I ask because Grails 1.3.5 has a bug which makes it ignore the environment parameter for grails war command, which might be a problem for you if are depending on "dev" environment being used)

What version of STS and the grails tools are you using?

Do you also get the same problem if you manually build and deploy the war file outside of STS (i.e. on commandline
1) grails clean
2) grails dev war
3) copy the created war file to the webaps dir of your tc server instance
4) start the server (you can do this inside of STS)

[bkane]

This is Grails 1.3.6 and STS 2.6.0.M1, 64-bit running on Windows 7 with JDK 1.6 update 22. So, it isn't the 1.3.5 issue with environments, any other ideas what it might be?

I will try the external deploy tonight and let you know. I assume you're looking to isolate this to an STS vs Grails vs tcServer issue? Is there anything else I can try to give you more information?

Thanks again for your help!

Brandon

[Kris De Volder]

Hi Brandon,

Yes, I'm trying to determine whether its an STS or "pure" grails issue. This is why I'd like you to try a manual deploy.

It's good to know it isn't the 1.3.5 environment issue. As to what else it may be I don't know. I'm really not an expert on Grails itself I just work on the STS tooling support and have little to no experience with actually building Grails apps.

However, it looks to me there's an issue with the database driver class not being found.

One thing you could try to get more info is to run the server in "debug mode" (easy from within STS, just clikc on the little "bug" icon instead of the regular start button). Before doing that, place a NPE breakpoint (in the debugger interface there a button that looks like a red exclamation mark, click on that to create a breakpoint triggered by an exception).

You should be able to make the debugger stop when the exception occurs and take a peak up the stack to see what the name of the class is that isn't being found (this might confirm my supsicion its something todo with finding the database driver on the classpath).

Kris

[bkane]

Hi Kris,

I tried a couple different things and got a bit more information.

First, I tried the external clean/dev war/deploy and was able to successfully start the application.

Debugging the startup indicated that the exception is caused by the loader trying to load a class where the name itself is null. From breaking further up in the createPool() method, I can see that all the properties of the pool are null, including the driverClassName, username, password, etc. Although oddly I did see the same NPE during startup in the console in STS when using the external build that did work, so I think this may be a red herring.

When building and deploying in STS there is another exception being thrown during my bootstrap which looks like it is the real problem, since it does not occur when building and deploying from command line. The stack is below. This is coming from the Audit Logging plugin (http://grails.org/plugin/audit-logging) which listens for changes to domain classes and creates AuditLogEvent entries. Given the error about the unknown entity I wonder if this is possibly a classpath issue with how these plugins are getting into the tcServer when deployed via STS?

The line at BootStrap$_closure1.doCall(BootStrap.groovy:211) creates a new User domain class and calls save(failOnError:true), which is what is killing the startup.

Let me know what else I can do to get you more info to debug this.

2011-02-28 20:41:53,423 [main] ERROR auditable.AuditLogListener  - AuditLogEvent save has failed!
2011-02-28 20:41:53,433 [main] ERROR auditable.AuditLogListener  - Unknown entity: org.codehaus.groovy.grails.plugins.orm.auditable.AuditLogEvent
2011-02-28 20:41:53,443 [main] ERROR context.ContextLoader  - Context initialization failed
org.springframework.beans.factory.access.BootstrapException: Error executing bootstraps; nested exception is groovy.lang.MissingPropertyException: No such property: errors for class: org.codehaus.groovy.grails.plugins.orm.auditable.AuditLogEvent
	at org.codehaus.groovy.grails.web.context.GrailsContextLoader.createWebApplicationContext(GrailsContextLoader.java:87)
	at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:197)
	at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4135)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4630)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:568)
	at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:637)
	at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:563)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:498)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1282)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
	at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:807)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445)
	at org.apache.catalina.core.StandardService.start(StandardService.java:519)
	at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:581)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
Caused by: groovy.lang.MissingPropertyException: No such property: errors for class: org.codehaus.groovy.grails.plugins.orm.auditable.AuditLogEvent
	at $Proxy16.saveOrUpdate(Unknown Source)
	at BootStrap$_closure1.doCall(BootStrap.groovy:211)
	at grails.util.Environment.evaluateEnvironmentSpecificBlock(Environment.java:251)
	at grails.util.Environment.executeForEnvironment(Environment.java:244)
	at grails.util.Environment.executeForCurrentEnvironment(Environment.java:220)

[bkane]

One mystery solved, the NPE was caused in both cases by an orphaned resource-ref in my web.xml. Same behaviour in both cases after fixing that issue, works when built and deployed externally, fails in STS, no NPE anymore.

[Kris De Volder]

OK, AuditLogEvent. That one is very familiar. I think you are experiencing some bugs that I fixed only recently. The fixes are not in M1.

https://issuetracker.springsource.com/browse/STS-1518
https://issuetracker.springsource.com/browse/STS-1539

This bug will be fixed (or should be) in the upcoming M2 release. Should come out any day now.

You could wait for that, or you could try upgrading to a nighly build. Be aware that there's actually two bugs involved in this problem and one of the fixes involves a patch to Greclipse so you'll have to also update your Greclipse from the Greclipse dev build update site.

It may be easier to wait for M2 as its supposed to be released TODAY :-)

[bkane]

Awesome, thanks Kris! I see that M2 has been released (on schedule!). I will try it out tonight hopefully and will let you know how it goes.

[bkane]

Closer, but still no cigar. I get about 50 lines further into my bootstrap when I get an error:

Caused by: org.hibernate.QueryException: could not resolve property: editedDate

The code in the bootstrap at this point is querying for a domain class which has an attribute (editedDate) that is added by the audit stamp plugin. The plugin adds editedDate/editedBy/createdDate/createdBy fields to all classes with the @gorm.AuditStamp annotation.

I tried the command line clean/dev war/deploy to tcServer and it worked as expected.

Any ideas?

Brandon

[Kris De Volder]

Sigh... It sounds like a similar problem than the bugs I fixed. Both of those bugs were related to AST tranforms.

The problem with those AST transforms is that they are very much dependent for their functioning on state and execution context that only exists when you run them as part of the commandline grails tools.

My guess would be this is also something like that, but it is only a guess. Is the editedDate attribute added by an AST transform?

Is there any chance that you could share your code with me, or, if not, condense down the problem you are experiencing to a small "recipe" to produce the problem.

If I can reproduce the problem I may be able to diagnose its exact cause and fix it somehow.