I am trying to pick up Grails using Groovy Grails tool suite. I tried to set up the tools to play around with Grails, unfortunately this issue which will need some advise. Please help me to resolve this problem.
These are the tools I had installed, using window 7:
1. Java JDK (jdk1.8.0_101)
2. Grails 2.3.4
3. Groovy Grails Tool Suite 3.5.1
Both Java and Grails are running fine. #cmd:
C:\Users\00Who00>java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
C:\Users\00Who00>grails -version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=32m; support
was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; sup
port was removed in 8.0
Grails version: 2.3.4
Grails 2.3 doesn't work with Java 8 because of the version of Groovy it uses; you need to use a newer version that uses a version of Groovy that's compatible. Either user Grails 2.4+ (or embrace 2016 and use an even more recent version) or switch to Java 7.
If you're getting started with Grails and attempting to use GGTS and Grails 2.3, I suspect you might be reading Grails in Action 2nd Ed. A fantastic book! Regardless, a couple of things to note:
Groovy-Grails Tool Suite has been discontinued for over a year, so is quite likely to have more issues
Grails 3.x is the latest and much improved (Gradle and Spock are defaults, among many other things)
For an IDE, I suggest switching to IntelliJ IDEA. If you are using Grails 3, both Ultimate and Community editions work fine since Grails 3 uses Gradle as a build tool. I'd definitely recommend the Grails 3/IntelliJ combo for getting up to speed, even if you need to switch back to 2.3 for work purposes. Nearly all the knowledge will transfer.
Available Grails 3 resources
There are no books yet on Grails 3 specifically. Here are some of the best resources I've found.
Grails 3 talks at SpringOne: infoq.com/conferences/springone2gx2015
Grails 3 User Guide: docs.grails.org/latest/guide/single.html
MrHaki's "Grails Goodness" series (which he offers compiled as a book also): mrhaki.blogspot.com/search/label/Grails%3AGoodness.
Beyond those, the Grails in Action 2nd Ed book is still very relevant and one of the best ways to get a comprehensive understanding of Grails.
Related
Is there a plan to update Orbeon CE logging to log4j 2.17 and if so, when?
We are aware that the current log4j 1.X version is not susceptible to the recent vulnerability, but other vulnerabilities are still present.
Orbeon Forms 2021.1 CE, coming out soon, will include Log4j 2.17 (or newer if they release yet another version in the next few days).
The vulnerabilities affecting Log4j 1.x affect things like SocketAppender and SMTP. We recommend for now that you don't use any networking feature with Log4j in your log4j.xml. Just use plain logging to files. If you do that, you are quite safe with Log4j 1.x, and possibly safer than with any version of Log4j 2 where vulnerabilities apparently keep being found :(
We haven't yet decided whether we would release fixes for earlier CE versions as the issues can be addressed entirely via configuration.
Establishing a maven cache path for Grails 2.5.6 applications has many side effects and I don't know if this is a known bug that I couldn't find reported or if I'm doing it wrong.
Our Grails applications (mostly in 2.0.4 version) have a grails.war.resources closure in the buildConfig.groovy that prevents certain static resources from reaching the war. However, for Grails 2.5.6 applications this closure didn't work until we created an empty ${HOME}/.grails/settings.groovy
Yes, empty (surprise 1). This situation happened both in Windows 7 using Eclipse Neon, and in a Red Hat Linux using Jenkins to build the applications.
Once we had this settings.groovy file we decided to use it to establish the maven cache path, so that both Grails and Java applications could share the same cache. The file contained one single line:
grails.dependency.cache.dir="D:/DEV-WAS8/CONF/m2/repository"
With this single line, building Grails 2.0.4 applications generated wars full of garbage because the grails.war.resources closure didn't work (surprise 2). This made no sense, but at least Grails 2.5.6 were built correctly. So we tried to establish the cache path only for 2.5.6 applications. The settings.groovy was the following one:
if (System.getProperty("grails.version")=="2.5.6") {
grails.dependency.cache.dir="D:/DEV-WAS8/CONF/m2/repository"
}
In this case grails.war.resources closure didn't work for 2.5.6 ones and 2.0.4 ones built correctly (Surprise 3).
grails.dependency.cache.dir being a System property, we established it at operating system level so that the settings.groovy file remained empty. Wars were generated correctly for both 2.5.6 and 2.0.4 but the maven cache path was not established correctly in Windows 7 using Eclipse Neon. However, it worked perfectly in Linux with Jenkins (Surprise 4).
How we solved it
To resolve the situation now we use an empty settings.groovy file and 2.5.6 applications establish the maven cache path in the buildConfig.groovy
The problem was that the grails.war.resources closure inside the buildConfig.groovy file was incorrectly nested within the grails.project.dependency.resolution closure. This, although incorrect, seemed to work in other Grails versions such as 1.3.7 and 2.0.4. However, the closure is not reachable any more in version 2.5.6 when nested. Once unnested it worked and war resources were filtered as expected
I've recently been trying to set up a Jenkins server that uses the Jenkins MKS plugin for version control. I had a Windows Jenkins server that was running this same configuration just fine, and now that we're moving it to a linux server (Red Hat Enterprise Linux Client release 5.1 Tikanga), it doesn't seem to be able to download the files. The folder structure is built perfectly fine, which tells me connecting to the server isn't the problem, but the files aren't populated in the folders.
Jenkins System Log:
Sep 02, 2016 11:15:46 AM WARNING org.apache.commons.httpclient.HttpMethodBase readResponseBody
Unsupported transfer encoding:
Sep 02, 2016 11:15:46 AM INFO org.apache.commons.httpclient.HttpMethodBase readResponseBody Response
content is not chunk-encoded
Sep 02, 2016 11:15:46 AM INFO hudson.model.Run execute
Test #67 main build action completed: FAILURE
Any suggestions on what I can do to check if my data/files are chunk encoded, or why this would be unique to a linux server? I realize we’re 3+ years behind on our configuration, but IT here has tight restrictions on what software can be installed and updated. Any troubleshotting suggestions or help is much appreciated!
Config Details:
Jenkins Version 1.596.3
MKS Plugin Version 1.16 MKS Server: MKS Integrity Client 2009, Build
4.10.0.9665, SP 007-01
Jenkins Slave info: Red Hat Enterprise Linux Client release 5.1
(Tikanga)
Java version 1.7.0 Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Server_VM (build 21.0-b17, mixed mode)
Similar issues / Research:
This issue report perfectly describes my problem, but the comment section suggests that the Java 7u40 update causes the issue, whereas I'm on an earlier version of Java.
https://issues.jenkins-ci.org/browse/JENKINS-21638
This issue describes the log error I'm seeing, but comment section suggests it was solved by Jenkins version 1.577. We're using a newer version of Jenkins. https://issues.jenkins-ci.org/browse/JENKINS-16985
You're using Integrity 10.9: As per the Version 2.0 (Jan 27, 2016) entry on the Plug-in's page:
IMPORTANT – PTC Integrity Plugin 2.0 is not backward compatible.
Please create new Jobs.
Productized version of PTC Integrity Plugin
compatible with PTC Integrity 10.9. Versions older than Integrity
10.9 are no longer supported.
I think what Cletus is trying to explain in that post is that both the version of Java used to build the plug-in and the version of Java running Integrity should be the same, and in the case linked for JENKINS-21638, changes in the 'File' object after Java 7u40 are preventing the plug-in from fetching files from the server.
If you were on a version of Java earlier than 7u40 (e.g. 7u25) it should work. Integrity 2009 SP6 (and hence the mksapi.jar file) were compiled with Java 6, so it's likely you're running into a similar issue there. Having said that, I'm working on an educated guess here, so you'd actually need to test that to see if it works.
Versions:-
Grails - 3.1.7, Groovy - 2.4.6, Java - 1.8.0, Operating System - Ubuntu 16.04
LTS
I'm able to create an application and run via command line interface (terminal) on ubuntu OS. But when I tried to import the same application (import as grails project) on GGTS the below error message is displayed.
'/home/shravan/grails/demo' doesn't look like a Grails project
Then I tried to create a new grails project from the tool suite itself and configured the grails installation and when I do so, this error message is displayed.
Command terminated with an exception:
org.grails.ide.eclipse.longrunning.client.GrailsProcessDiedException:
Grails process died (see details for partial output) Grails process
died
------System.out:-----------
------System.err:----------- Error: Could not find or load main class org.codehaus.groovy.grails.cli.support.GrailsStarter
Error: Could not find or load main class
org.codehaus.groovy.grails.cli.support.GrailsStarter
I'd like you guys to help me resolve this issue as I'm new to this grails application. Your help is much appreciated.
GGTS does not support Grails 3. Nobody has been maintaining GGTS for over a year, so it doesn't look like it ever will support Grails 3. I recommend switching to IntelliJ instead.
Like Donal mentioned, GGTS doesn't support Grails 3 and it is not been maintained. So it's better you use IntelliJ.
The biggest advantage of IntelliJ is that it's very fast and developer friendly and you can use Grails 3 on it's free community version since Grails 3 is based on Gradle.
https://www.jetbrains.com/idea/download/
I have a JSF 2.0 web project and I use Glassfish 3.1.2 server. In this project, I have among other things :
a class called AjaxServlet annotated with #javax.servlet.annotation.WebServlet
a class called Session annotated with #javax.ejb.Stateful
When I deploy this project to Glassfish from eclipse, everything runs perfectly : in the administration console of Glassfish, the engines associated with the application are [ejb, jpa, web, weld]. But when I first export the project as a war, then from the admin console I deploy the war, the application doesn't work : the engines associated to the application are then [web] only.
How can I export an application to a war without loosing any information (all the engines)? I didn't declare my Servlet in web.xml because in JSF 2.0, we don't need that: the annotations are enough. Does anyone have an idea about what is going on here? I'm quite sure it is not a problem of Glassfish distributions (Web Profile Vs Full Platform) as the same Glassfish server is used for the 2 scenarios above.
Note for those who erroneously think my question is off-topic : Jsf is a framework for programming Java EE web applications. war is a way to package a Jsf application, in the same as jar is a way to package java classes. So my question is totally a programming topic! It is totally legitimate to have it here in StackOverflow. If exporting JSF application into war is not a programming issue, then compiling java classes into .class should not be a programming topic neither! So Pleaze don't downgrade for this reason!
You have to understand the difference between your eclipse environment and your glassfish environment. Not all your libraries that are available in eclipse might be included in your external environment. There are cases where programs compile in eclipse, but not when run from console.
Here's a tip:
Right click on project -> Navigate to Properties > Java Build Path > Order and Export, and ensure that all libraries you require are going to be exported.