I've got a Tomcat6 server that runs multiple Instances for two separate grail apps.
When I compile my WAR file for deployment normally
run-app -Dgrails.env=production war test.war
It deploys correctly and everything works as it is suppose too.
The problem is, I don't want the JAR files included in my WAR.
So I use the following command line instead
run-app -Dgrails.env=production war test.war --nojars
Now when my grails app deploys (it doesn't) I get a java.lang.NoSuchMethodError
I have copied the lib folder (from my initial test.war) to the following locations
${catalina.base}/shared/lib
${catalina.home}/shared/lib
${catalina.home}/lib
None of these work.
My catalina.properties all point to the correct locations.
Any ideas?
A few ideas:
BuildConfig.groovy has inherits global, which has the app inherit all of the grails/plugins dependencies. If you change this, it may affect both your build and packaging - plus I have yet to encounter any documentation on what type of other things you can do with the inherits DSL
Grails deployment documentation suggests there is a way to customize which dependencies make it into the war file: http://grails.org/doc/latest/guide/17.%20Deployment.html
Event hooks give you access to provide a closure routine into various stages of the grails lifecycle. Can it strip out framework jars from the final war? Haven't tried that either - only using it to re-write various config files for additional envrionment configuration. However it does look like packaging events are exposed to this API:
http://grails.org/doc/latest/guide/4.%20The%20Command%20Line.html
Related
We have an application that until recently was a single Maven WAR project. We were using the Tomcat Maven plugin to run the application on local developer workstations using:
mvn tomcat:run
We were able to change JSP files while the embedded Tomcat instance was running and the changes would appear in web browsers just fine. I understand (from the plugin documentation) that when using the tomcat:run goal, the WAR is loaded as a dynamic web application and hence changes made to JSP files at source are picked up by Tomcat at runtime without restart.
The application has reached a fairly large size and we needed to reuse a large number of classes in a few different places besides the web project, so we refactored the code base into a multi-module Maven project. The structure is now:
parent Maven POM
|
---- artifact1.jar
|
---- artifact2.jar -> depends on artifact1.jar
|
---- artifact3.jar -> depends on artifact1.jar
|
---- artifact4.jar -> depends on artifact2.jar and artifact3.jar
|
---- artifact5.war -> depends on artifact1.jar, artifact2.jar, artifact3.jar and artifact4.jar
After the refactoring we were unable to use tomcat:run from the project's root directory to run the WAR project as the plugin was unable to detect the JAR artifacts. So, we switched to using the tomcat:run-war-only plugin. The WAR module now launches fine.
However, from the documentation, it seems that the run-war-only goal treats WAR files as packaged web applications. Therefore, any changes we make to JSP files now are not picked up by the embedded Tomcat server while running. For every change to JSP files we have to restart the server.
Is there a way for us in this multi-module Maven set up to run WAR projects as dynamic web applications so that at least changes to JSP files are picked up by Tomcat without restarting?
Just do an mvn install first and then
mvn -pl artifact5 tomcat:run
First use new version of the tomcat plugin now located at Apache see http://tomcat.apache.org/maven-plugin-2.0/.
Then if you use maven3, you simply use tomcat6/tomcat7:run from the top. All classes from modules will be added to your webapp classloader (will save some ios as you don't need to install all jars first !) see http://tomcat.apache.org/maven-plugin-2.0/run-mojo-features.html
HTH!
I need to set a different classpath for one single grails xxx command.
The point is that my application uses latest version of commons-httpclient. I have no problems with this. But after building my application I need to use grails maven-deploy to store my war file in a webdav repository, and the command conflicts with the latest version of commons-httpclient. This command works great if I add commons-httpclient-2.0.2.jar in the classpath (lib folder for example), but the app will fail on trying to use the regular features that depends on commons-httpclient.
I need to add this other jar in the classpath just for running the maven-deploy command, any ideas?
I'm using jenkins (huson) to build the app, so, any tips on making the solution achievable with grails jenkins plugins will be appreciated.
Thanks a lot,
Does the grails maven-deploy command conflicts due to another dependency on httpclient?
Which one is it? May be you could exclude the dependency it?
There are several tutorials and even some posts here about shrinking .war files. However, the most common technique (to include grails.war.resources = {} in Config.groovy) does not seem to work for me. No matter what, grails dumps everything into the war file making a 25meg .war. Has this functionality changed? Grails 1.3.4
Im on 1.2.0
grails war --nojars
creates a war with no jars.
You have to make sure your jars are properly installed on wherever you are deploying, so
$tomcat/shared/lib
for tomcat.
For tomcat6 and later remember to update your catalina.properties file:
shared.loader=${catalina.home}/yourDirectoryName/*.jar
You will need to ensure that ${catalina.home}/yourDirectoryName exists and that it contains all the grails WEB-INF/lib jars in it.
I have two configurations I need to change after building a prod war with grails 1.3.2. I know the project can be setup in ways to do this externally in the first place, but that's not an option at this moment.
1) Need to change environments.production.hibernate.default_schema defined in DataSource.groovy
2) Need to change environments.production.grails.serverURL defined in Config.groovy
Is there any way to edit the war or pass overriding arguments when running the war in JBoss?
If you want to change these properties in a production application with out redeployment your out of luck. Your only option is using external properties files which will require a rebuild and redeployment of the app. See the following link. http://www.comitservices.com/wp/?p=133
I started a grails application by grails create-app. For modularity, I feel like it would be better that component be a plugin. Can I convert this application into a grails plugin?
thanks,
Babu.
I never created a plugin based on an application written before but looking at the documentation for grails plugins you can read the following statement:
The structure of a Grails plugin is exactly the same as a regular Grails project's directory structure, except that in the root of the plugin directory you will find a plugin Groovy file called the "plugin descriptor".
So I would suggest to create a new plugin with grails create-plugin *your-plugin-name* and copy all files from your application into the plugin.
In case anyone else is looking, this should be exactly what you need: http://burtbeckwith.com/blog/?p=1973
Excerpt:
So to convert an application to a plugin, the general workflow would
be something like
Create the plugin descriptor, FooGrailsPlugin.groovy. The easiest way to do this is to rungrails create-plugin pluginname and copy the
generated file from there
delete everything from application.properties except the app.grails.version property
if you have jars in the lib directory that are available in a Maven repo, delete them and replace with BuildConfig.groovy dependencies
change any plugin and jar dependencies that are needed for development and testing but not when the plugin is installed to not be
exported, by adding export = false
If you need the _Install.groovy, _Uninstall.groovy, or _Upgrade.groovy scripts (you probably don’t) grab those from the dummy plugin from step 1 (but delete any you don’t need, they’re all
optional)
delete ApplicationResources.groovy if you aren’t using it and don’t depend on resources plugin
move code from BootStrap.groovy init() toFooGrailsPlugin.doWithApplicationContext
and/orFooGrailsPlugin.doWithDynamicMethods and destroy() to
FooGrailsPlugin.onShutdown, and delete BootStrap.groovy
add a dependency for the release plugin in BuildConfig.groovy
delete everything but the log4j configuration from Config.groovy
delete UrlMappings.groovy unless you have exported mappings; only keep the added ones
move bean definitions from resources.groovy to FooGrailsPlugin.doWithSpring and delete resources.groovy
delete grails-app/i18n message bundle files unless you added messages; only keep the added ones
delete everything from grails-app/views that you don’t use (in particular error.gsp,index.gsp, and layouts/main.gsp)
delete everything from web-app that you don’t use (including WEB-INF xml and tld files)
now would be a great time to write those tests you’ve been meaning to get to
create one or more test applications to install the plugin into to ensure that it works as a plugin; consider scripting this
write documentation for how to use the plugin; at a minimum a README file, but Grails gdoc files would be much better (run grails doc
--init to get started)