Latest version of STS (e.g. 3.7.3) does not support Grails anymore so I'm using STS Gradle projects as workaround in order to run my Grails applications with "Spring Boot App" option. It's working just fine, but I have faced the issue below:
Issue:
Somehow all the beans declared under resources.groovy file have been ignored when I execute the application via STS running as "Spring Boot App". Notice that running the application via console "run-app" command it works fine.
Exception:
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'facebookAuthRedirectFilter': Cannot resolve reference to bean 'redirectFailureHandlerExample' while setting bean property 'authenticationFailureHandler'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'redirectFailureHandlerExample' is defined
My resources.groovy file
package spring
import org.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler
beans = {
redirectFailureHandlerFacebook(SimpleUrlAuthenticationFailureHandler) {
setDefaultFailureUrl('/login/auth')
}
}
STS:
Version: 3.7.3.RELEASE
Build Id: 201602250940
Platform: Eclipse Mars.2 (4.5.2)
Grails:
Grails Version: 3.1.1
Groovy Version: 2.4.5
JVM Version: 1.7.0_75
It seems classpath issue but I could not find how to resolve this yet.
Issue resolved by updating Groovy compiler settings. Go to Window->Preferences->Groovy->Compiler, see below:
Doing this resources.groovy will be compiled and the beans will be available on run time.
Related
I am running grails 3.2.1 and want to create Swagger-documentation for my REST endpoints. I added the SwaggyDoc-plugin to the dependencies in my build.gradle script by adding:
compile "org.grails.plugins:swaggydoc-grails3:0.28.0"
And configure it by https://rahulsom.github.io/swaggydoc/ .
In IntelliJ I see the Swaggydoc-dependency added to my list of libraries.
After starting my Grails-application via the grails run-app command and opening my application by entering http://localhost:8080/api/ I get an swagger-ui index.html, but I find error in console log(see in image).
console log errors
And this exceptions in grails.
ERROR org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/].[grailsDispatcherServlet] - Servlet.service() for servlet [grailsDispatcherServlet] in context with path [] threw exception
org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object '[Digest Input Stream] MD5 Message Digest from SUN
Answer
When we create grails application inside intellij we will get the following dependency inside application.yaml file.
runtime "com.bertramlabs.plugins:asset-pipeline-grails:2.11.6"
We need to replace this with the following :
runtime "org.grails.plugins:asset-pipeline"
This error will be resolved.
After making changes in my grails application, if I try to call 'run-script' I get the following exception:
Error org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'grailsApplication'
...
The extended exception will vary, depending on what changes you've made to the application.
This is occurring on grails version 2.3.1.
It turns out that 'run-script' (at least in version 2.3.1 of Grails) does not run 'compile' before it tries to run!
So, the solution is:
grails compile
grails run-script myScript.groovy
I am working on a grails app and have been trying to deploy it to glassfish . However, during deployment I get the following error:
From server logs:
[#|2013-04-16T07:53:21.540-0400|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=91;_ThreadName=Thread-1;|2013-04-16 07:53:21,540 [admin-thread-pool-7720(2)] ERROR context.ContextLoader - Context initialization failed
org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is **java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V**
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:420)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:342)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:310)
……
On my system classpath I have the following files:
slf4j-api-1.5.6.jar, slf4j-api-1.5.6.jar, slf4j-log4j12-1.5.6.jar.
I believe the problem is that Grails is trying to load the method from slf4j 1.6 (I am on Grails 2.1.0). I want Grails to use its the webapps classpath rather than using system classpath.
How do I do this ?
If I'm not mistaken you cannot have two versions of the same library in your container, so you need to upgrade the version that's in your classpath to 1.6
I'm developing with Grails 2.1.1 and now I want to integrate Logback (http://logback.qos.ch) as the default logging framework as it should provide some better logging features and could be also configured via Groovy.
As Logback 1.0.7 (latest) does only work with slf4j 1.6.6 I want to upgrade the Grails dependeny. Grails 2.1.1 is using slf4j 1.6.2. How to do this properly?
I tried the following: in BuildConfig.groovy I exclude grails-plugin-log4j and slf4j-api
grails.project.dependency.resolution = {
// inherit Grails' default dependencies
inherits("global") {
excludes "grails-plugin-log4j", "slf4j-api"
}
...
}
and I try to load slf4j-api 1.6.6 in compile build and runtime along with the other necessary libraries
grails.project.dependency.resolution = {
...
dependencies {
// specify dependencies here under either 'build', 'compile', 'runtime', 'test' or 'provided' scopes eg.
compile "org.slf4j:slf4j-api:1.6.6"
build "org.slf4j:slf4j-api:1.6.6",
"ch.qos.logback:logback-core:1.0.7",
"ch.qos.logback:logback-classic:1.0.7"
runtime "org.slf4j:slf4j-api:1.6.6",
"org.slf4j:log4j-over-slf4j:1.6.6", // logback dependency for classic module, as seen on http://logback.qos.ch/dependencies.html
"ch.qos.logback:logback-core:1.0.7",
"ch.qos.logback:logback-classic:1.0.7"
}
...
}
now, if I want to do anything from the Grails commandline, either grails compile or grails clean, it's complaining that it couldn't execute the script because it couldn't find the LoggerFactory class:
| Loading Grails 2.1.1
| Configuring classpath
| Error Error executing script Compile: org/slf4j/LoggerFactory (NOTE: Stack trace has been filtered. Use --verbose to see entire trace.)
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:156)
at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:132)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:272)
at org.springframework.core.io.support.PathMatchingResourcePatternResolver.<clinit>(PathMatchingResourcePatternResolver.java:169)
| Error Error executing script Compile: org/slf4j/LoggerFactory
How can I upgrade the underlying slf4j-api properly?
If I don't exclude the slf4j-api first, I get a conflict with the "old" 1.6.2 api marked as evicted when calling grails dependency-report...
Also, I'd love to have an external config file for Logback. How would I implement it? With Log4j I just declared a log4jConfigurer bean within the conf/spring/resources.groovy file - how would it be done with Logback?
Has anybody experience in logging Grails 2.1.1 with Logback and could give me any advice for this issue?
As I think that this question would be also a matter of fact for other developers willing to implement the Logback Logging Framework with Grails, I'll share my progress on the topic within this answer - trying not to overload the initial question with progress information.
I still had no luck in updating slf4j within Grails, so I stuck
with the solution to simply overload the slf4j-api dependency.
Grails would show no error on grails dependency-report, just an
"eviction notice" on the older slf4j dependency (1.6.2). This seems
to work but I'll keep on searching for a better solution on this
topic.
I'm now able to load an external config file for Logback through
a ServletContextListener and a ConfigLoader class
implemented in grails-app/src/java, with the
ServletContextListener registered within the web.xml file. (to
get the web.xml simply execute grails install-templates on the
commandline. You'll find it under
grails-app/src/templates/war/web.xml) Be sure to make it the first
<listener/> entry within your web.xml so that Logback gets
configured and loaded as soon as possible.
I found this solution along with the full code sample over at
https://bowerstudios.com/node/896 which was the best and shortest
example I found on this topic which seems to work!
This solution just loaded the external configuration file and used
it within the ConfigLoader class but didn't set it for the whole
Grails application. So I googled around a bit more and I found a
solution from Logback, available at GitHub (https://github.com/qos-ch/logback-extensions) and integrating with the
Spring Framework, so I took these classes from this page and
the LogbackConfigurer class from here and tweaked them to fit
my needs.
Now everything works like a charm and I'am able to create an external configuration file and - what I like best - it's hooking in
with the log object which is injected to e.g. Controller classes
by default.
Hope this is also a help for other developers too ;)
If you've got a better or more "groovy" solution for this, pleas let me know!
I'm using datasources in my Grails project.
When I edit a groovy file with server running I get the following error:
Running Grails application.. java.lang.IllegalArgumentException: Must
supply a resource type for JNDI configuration
How can I configure grails.naming.entries in Config.groovy to fix this?
Note: I'm using grails 1.3.6
Tks
I'm using 1.3.7 and hit the same issue. There's a couple bugs in the JIRA about this, looks like they were finally fixed in 2.0-M1. There's a patch for 1.3.1+ versions here, but I haven't tested that yet.
Link to possible patch: http://jira.grails.org/browse/GRAILS-7021