Running into a problem with an existing application. I'd like to get hundson running to do some CI but I cannot modify the Websphere settings (making changes appears to break the application that I want hudson to test against!)
So this is my current error message:
We detected that your servlet
container is loading an older version
of Ant by itself, thereby preventing
Hudson from loading its own newer
copy. (Ant classes are loaded from
bundleresource://22/org/apache/tools/ant/types/FileSet.class)
Perhaps can you override Ant in your
container by copying one from Hudson's
WEB-INF/lib, or can you set up the
classloader delegation to child-first
so that Hudson sees its own copy
first?
Without changing the classloarder delegation (which breaks the existing app) is there a way to update Websphere's ant library? I don't even know where it is, I tried searching for ant-lr but came up with many results.
Any help would be appreciated.
Why dont you run Hudson on a separate app server? You can even run it from the embedded servlet container directly from the war.
If you really need to run it on websphere look at the wiki.
http://wiki.hudson-ci.org/display/HUDSON/IBM+WebSphere#IBMWebSphere-KnownIssues
Read http://wiki.hudson-ci.org/display/HUDSON/IBM+WebSphere. It states specifically that you must set child-first class loading on WebSphere 6.1.
Related
In grails 2 and earlier, plugins installed their source to .grails/<version>/projects/<projectName>/plugins/etc, this made it easy to debug plugins that were installed without having to check out and load the full source... find where problems were that could be hot-deployed. No need to install run the plugin locally.
In grails 3, this seems to be missing... or maybe I'm just missing something? Is there somewhere in my project I can directly modify the plugin source without checking out the plugin, compiling it and then installing it locally?
Yes, you're missing something rather important :)
Grails 2 plugins are distributed as ZIP files including source code, but Grails 3+ plugins are distributed as JAR files with the code compiled into classes. This has multiple benefits over the earlier approach, the biggest one being that you can no longer edit the source directly (which is the worst way to make changes to how a plugin works).
What you should do instead (in all versions of Grails) is to take advantage of the compilation/load/resolution order between the app and the installed plugins - plugins load first, then the app. This allows you to override nearly anything in a plugin just by creating a file (Groovy/Java/GSP/etc.) with the same name and same relative location in your app code, and it will automagically override the plugin's file or class. E.g. to override a plugin's com.foo.BarController controller, create grails-app/controllers/com/foo/BarController.groovy in your app (manually or by copying the original source and modifying it).
I have a larger Grails project for which I have taken over development. I have used Grails before and one of the features that I found really nice-to-have is the auto-compilation/reloading when developing.
I haven't had to do anything special to make this work in the past, however for some reason it is not triggered for this project.
I do a simple "grails run-app" and modify a file when server is started - nothing! Any suggestions?
Windows 7, Grails 2.0.1, Java 1.6u35
IDE: Groovy Grails Tool Suite 3.1.0.M1 - Based on Eclipse Juno 4.2
Grails command line doesn't seem to properly handle spaces in directory names of GRAILS_HOME or HOME directory.
see:
http://jira.grails.org/browse/GRAILS-7936
it has links to various other related issues.
This comment has a workaround: http://jira.grails.org/browse/GRAILS-7936?focusedCommentId=72170&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-72170 .
Are you using eventCompileStart in scripts/_Events.groovy? That was my problem, see GRAILS-8776 (please comment and vote on that issue if this is your problem so we can get it resolved!).
Commenting out that block cause auto-reloading to start working again for me.
My solution:
Right click on project -> Properties -> Project Facets -> check Java and set it's correct version -> OK
Bingo!
Is there anywhere that can give you a tutorial or anything on creating a Debian package using Ant?
I'm being told its already a part of Ant but I've never seen any functions even remotely associated with it.
I don't want to use ant-deb-task either seeing as its not actually part of Ant.
There is no task for this in the core Ant distribution.
There are examples for ant-deb-task available in the examples file on the download page.
Another option is jdeb which also provides documentation.
Hey all,
I'm just starting with Grails in Netbeans (6.9.1). I got a demo working, but each time i change a groovy file i need to build the project, and then select run (ie the equivalent of "grails build" and "grails run-app"). If there is already an instance running, I need to first shut that instance down.
This seems wrong. It seems like i should be able to just change the groovy file, and it would get automagically reloaded. Isn't that the point of groovy?
Is this actually how it's supposed to work in Netbeans? Without getting into an IDE war, do other IDEs do it better? everyone seems to rave about the Grails support in IntelliJ. Is it worth it?
One last point... I noticed that a regular war maven project no longer automatically reloads on an F11 build. Could this be related?
Thanks
--Matthias
Do not expect to have reloading for all your files even by running your grails app through command line.
Depending on which groovy file you have changed, grails run-time auto-reloading will work or not. Indeed:
Files and folders supporting reloading in development mode: gsp files (in view folder), grails services (in service folder), controllers, taglibs, css, i18 resources, javascript files, some config files (like Config.groovy), url mappings. Note that there are some Grails bug when for instance, using spring transactional annotation in Services makes the reloading crashed
Files and folders NOT supporting reloading (and requiring a restart of the application): any code under src/groovy, src/java, Domain classes (under domain directory), some configuration files, changes in plugins, any code under utils folder (if you have any Codec for instance)
So in your case, if you change a controller groovy file AND NetBeans restarts the application, I recommend you to use a separate command line for running grails application and using the IDE for code changes. The only bad side is that you will not use the NetBeans debugger.
Actually this is the way I work with Grails and IntelliJ
Help! I'm porting a large ruby app to Grails - but the Grails startup of my application takes more than 2 minutes.
I've already set dbCreate to "read" I've ensured my high end dual processor desktop windows box gives Grails needed RAM (1 Gig). I have no plugins installed. I have 170 domain classes that used to be ruby classes.
When it starts up it prints out the line "Running Grails App.." and then hangs for a long time before it then prints out the "Server running" line.
I just did something where I migrated all my ids to bigints. That seems to have worsened the problem. Now it takes about 10 minutes to startup.
I am new to grails would you please give me a few more details on what and where to log the events at startup? As to profiling the vm, its been a few years since I did a lot of Java. What do you recommend as the best profiling tool to use now?
What else can I do to speed up Grails startup?
Unfortunately, I am not sure too much can be done beyond what you already did. As you know, there is a lot going on when it starts up, with all the plugin resolution / loading, adding dynamic methods to your domain objects, and overall dynamic nature of Groovy.
I am not sure which version you are using, but I've asked for ability to turn off dependency checking when you start up in 1.2, since that adds a bunch of time to startup time as well.
I realize above isn't too helpful, so perhaps this will be: I split up my application into several plugins. One for domain objects, one for graphing capability, one for excel import, another for some UI constructs I needed. I didn't do it just because of slow startup times, but the advantage is that I can test parts of the system separately from each other before integrating everything together.
I am about to add a piece of new functionality that involves at least 10 new domain objects, and I am first developing them in a separate plugin by having stubs for the few objects they have to interact with from the core app. That allows me to both reduce startup times, and also have my code better isolated.
So if it's an option for you, try to separate out things so you can work on them separately, which will alleviate your issue somewhat. There may also be other benefits in terms of having your team work on smaller components separately, better modularization, etc.
Hope this is helpful.
170 domain classes is fairly large, but 2 minutes still seems really long to me. Do you have a ton of plugins installed? Potentially too verbose debug settings?
I'd be curious how long it took if you created a fresh grails app, copied in all of your domain objects (and the subset of plugins that the domain objects might need to actually operate) and see how long that takes to start.
Jean's suggestion about separating things out if possible is a good one. I've done something similar on previous projects where we have a domain plugin, and our other apps all rely on that domain plugin.
You could also use the grails events to log some timing information on start up to see where your bottlenecks are. Timing the "PluginInstalled" event should be good as I think that the hibernate plugin would be caught by this in addition to the other plugins.
You may have a dependency problem. If a plugin you use relies on a library in maven that has 'open ended' dependencies, grails will go and look each time if there are newer versions to download in the range. I have no idea why anyone would specify it like this. It seems it would lead to unreliable behaviour. For me, the culprit is Amazon's java aws library, naturally used by a plugin that talks to Amazon's cloud.
http://mvnrepository.com/artifact/com.amazonaws/aws-java-sdk/1.2.10
note how some of its dependencies are like this
org.apache.httpcomponents httpclient [4.1, 5.0)
it appears that every time, grails is looking for a newer version (and downloading if it exists, I just noticed 4.2-alpha1 of httpclient come down when I ran this time).
By removing that dependency from the plugin and manually adding the required libraries to my .lib folder, I reduced my startup time from >30sec to <1sec
You might want to see if there are other knobs you can turn other than Grails in order to fix this.
Have you tried approaching this as a performance issue? You can a look at the box performance and try to find out what the bottleneck is. Is it CPU? Is it a disk read issue? Can you attach a profiler to the VM and find out what's using up most of your startup time?
Have you tried basics like these for further deployment to a servlet container of your choice or in-place .war bootstrapping?
grails -Ddisable.auto.recompile=true run-app
grails run-war
grails war