Using the requestContext demo example in my system
http://www.primefaces.org/showcase-labs/ui/requestContext.jsf
I am getting the following error
Caused by: java.lang.ClassCastException: org.primefaces.context.DefaultRequestContext cannot be cast to org.primefaces.context.RequestContext
at org.primefaces.context.RequestContext.getCurrentInstance(RequestContext.java:38) [primefaces-3.4.1.jar:]
the error occur when the java command running
RequestContext context = RequestContext.getCurrentInstance();
Using primefaces-3.4.1 under jboss seam 2.3.0.Final with Jboss AS 7.1
Amir
You've multiple different versioned PrimeFaces JAR files in your webapp's runtime classpath. For example, one PrimeFaces 3.3 and another PrimeFaces 3.4.1. They're conflicting with each other.
Cleanup the webapp's runtime classpath so that only the most recent version remains and this problem should disappear. Paths which are by default covered by the webapp's runtime classpath are the webapp's own /WEB-INF/lib folder, server's and/or JRE's own /lib and /lib/ext folders.
Update: another, actually more rare, cause is that you've multiple PrimeFaces JAR files of the same version which are loaded by different classloaders. The getClass() on the both classes would then never match the == check. You'd need to remove one of both.
Related
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 have a Grails app that uses the Rest plugin
When I drop my war into my JBoss deploy directory and start it up, the deployment of the app fails because of the following error:
2012-11-01 15:48:33,931 ERROR [org.jboss.web.tomcat.service.deployers.JBossContextConfig] XML error parsing: context.xml
org.jboss.xb.binding.JBossXBRuntimeException: Failed to create a new SAX parser
I believe this refers to the grails app containing a version on xercesImpl as well as JBoss having it's own. We usually rectify this by removing xercesImpl from our apps or setting them to "provided" scope.
I'm trying to figure out how I fix this deploy issue. I'm assuming I have to edit the BuildConfig.groovy script and tell it, somehow, to exclude xerces right? How would I do that for this plugin? If this were a "dependency" that appears to be easy to specify the exclusions. But I'm not sure how to do it for this plugin...
any ideas?
In your BuildConfig.groovy add this:
inherits('global') {
excludes 'serializer'
}
It turns out, doing the following in the plugin section of my BuildConfig.groovy did the trick after all...
compile(":rest:0.7"){
excludes "xercesImpl"
}
When I'm deploying JSF2.0 application on tomcat6.0 I'm getting following exception:
com.sun.faces.lifecycle.ELResolverInitPhaseListener populateFacesELResolverForJsp
INFO: JSF1027: [null] The ELResolvers for JSF were not registered with the JSP c
ontainer.
I have included el-api2.2 and el-impl2.2 jar files in $TOMCAT_HOME/lib directory,as well as i have also included el-impl2.2.jar in my Project lib's folder.
I have included el-api2.2 and el-impl2.2 jar files in $TOMCAT_HOME/lib directory
Remove them. They don't belong there.
i have also included el-impl2.2.jar in my Project lib's folder.
If I guess right the concrete functional requirement which you didn't tell anything about, then you actually just want to get EL 2.2 to work on Tomcat 6.0. In that case, you should drop the mentioned JAR files in /WEB-INF/lib folder of your webapp and add the following entry to webapp's web.xml, assuming that you're indeed using Mojarra JSF implementation as hinted by the exception.
<context-param>
<param-name>com.sun.faces.expressionFactory</param-name>
<param-value>com.sun.el.ExpressionFactoryImpl</param-value>
</context-param>
Because of memory constraint i am trying to build a grails app with smaller memory footprint. I build the war with this argument "--nojars". I created a war file without all the jar and when i deploy within the glassfish i encounter this error
Exception while loading the app : java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: java.lang.ClassNotFoundException: org.codehaus.groovy.grails.web.util.Log4jConfigListener
It seems like the application fail to find where is the jar file.
I had already indicates the path to the library before deploying the application in glassfish.
did i miss out somethinng?
It is commonly recommended to use GlassFish's Common Classloader. That means putting the shared JARS into the $domain-dir/lib folder (but not into a subfolder of that).
You're probably trying to use the Application Classloader with the asadmin deploy --libraries command. This is more complicated and error-prone. If you don't need different versions of the same JARs with different web applications, you should definitely go for the Common Classloader as specified above.
Also see The Classloader Hierarchy for a reference.
EDIT Updated as per the questioner's comment:
The domain/domain1/lib folder definitely works (I've tested that). To validate that, put log4j.jar into that folder and add a test.jsp to domain1/applications/$applicationName, that just contains:
<% out.println(
org.apache.log4j.Logger.getLogger(this.getClass())); %>
If that works but your other code does not, there may be another point to consider: Are you using Log4J's Logger.getLogger(..) or Apache Commons' LogFactory.getInstance(..) in your code?
See the article Taxonomy of class loader problems encountered when using Jakarta Commons Logging for related issues. - I'd also like to advise you to post your complete stacktrace.
I have an example Grails application (from Grails in Action) that was created a while ago under version 1.1.1 on a different PC.
I am now loading Grails 1.2.0 and want to revisit the app. However, when I try to run it I get this message:
Application expects grails version [1.1.1], but GRAILS_HOME is version [1.2.0] - use the correct Grails version or run 'grails upgrade' if this Grails version is newer than the version your application expects.
After reading around a bit I cleared out the 1.2.0 folder under .grails in my home directory (from previous attempts while exploring the issue), ran "grails clean" and "grails upgrade" (answering "y" where prompted).
However, I consistently get "Invalid duplicate class definition" conflicts between classes in \grails\qotd\src\java and \grails\qotd\grails-app{controllers,services,conf}.
Are there any additional manual steps that I need to perform?
I understood your problem.
The solution is just modify the grails vesion to 1.2.0 in application.properties file in your application
If, as you pointed out in the comments, your /src/java contains .groovy files - that could definitely cause unexpected behavior. I haven't hit your particular issue, but any time I had a .groovy file mismatched with the class name inside it, I'd get strange compilation issues - so I guess you could be having a similar issue.
If you have files / classes with the same names in two locations, that's the likely culprit. If you have .groovy files in /src/java, that's another potential source.
Also, putting BootStrap, Config, DataSource and URLMappings into /src/java, that's another potential source of issues. I'd clear out your /src/java by making sure all the files are in their appropriate places under grails-app.
You can upgrade grails version with 5 steps
Project -> Clean
application.properties -> Change app.grails.version
Your project -> Properties -> Grails -> Change grails installation
to new grails version.
Your project -> Grails tools -> Refresh Dependencies
I think this may be help you