My grails application depends on several grails plugins that append and entries to web.xml
The problem is I need to control the order the plugins are executed. There is a particular plugin which is used for some security purposes which adds a filter in web.xml. This filter needs to be the first executed filter in web.xml Thus I would like this filter to be executed last so that I can ensure that this plugin will be appending the configurations in the first position.
I know there is a dependsOn property on the plugin class to ensure it gets executed last, but that only works if I know which plugins are going to be used in combination with this plugin. I would like this plugin to be general enough so that anyone in my company can use this plugin and know for sure that this gets executed last.
Is there any way I can ensure a particular plugin gets executed last? Either in the grails-plugin project (ie a property of the plugin class) or configuration of the grails application project.
Thanks,
Does the grails application install plugins using the install-plugin command? If so, try declaring them in BuildConfig.groovy instead.
plugins {
runtime ':weceem:0.8'
runtime ':hibernate:latest.release'
}
It's possible that plugins declared here are loaded in the same order they're listed, though I haven't tested this theory.
It might be easier to find a way to make your plugin append it's filters differently to ensure they get appended to the position you want them in. I would have to see the code for the plugin if I was going to try to help solve this in that way though.
Related
I'm develping custom Jenkins plugin.
As part of the development I had to make some changes to the classes and fields of my custom build step.
As a result, each client that updates the plugin has to re-enter the configuration of some of the fields.
I wonder if there is a way to load the old values and map them to the new fields?
Any help will be appreciated.
Cheers,
Nadv
See Hint on retaining backward compatibility in the Jenkins wiki. It covers all relevant cases, e.g. adding/removing/renaming fields.
Grails Version: 2.3.11
Dear all,
I have a plugin where in the doWithSpring Closure I use some central resources to build up a properties file in the war that is then used during runtime. The central resources will only be available when building the war in a production environment so putting the files into the /src (for example) of the plugin is out of the question.
Currently my plugin will work in a run-app and testing environment, but the file is never created when 'war' is run.
I have tried setting the scopes variable to include war but this doesn't appear to be doing much (or at least, is not invoking the doWithSpring closure). Does anyone know how to do this or if it is possible?
All of the logic is within doWithSpring (which delegates to a class) but that is only using the classLoader and grailsApplication so if there is anywhere else I can do this that will also be great.
Thanks
Adam
Okay, the best approach is to hook into the events with your plugin. I highly recommend you read the documentation on events. It's as simple as creating the correct file within your plugin and placing your code within the associated closure.
For example:
scripts/_Events.groovy
eventCreateWarStart = { warName, stagingDir ->
// place your code here.
}
I'm creating a Grails plugin which will modify the value of the following config property:
grails.gorm.default.constraints
The problem is that by the time my plugin descriptor starts running (doWithSpring) if the Grails application that uses the plugin had an existing value for the default constraints property, it would have been already executed.
I'd like my plugin to modify the value of the default constraints before Grails begins executing it so that the constraints I'm adding will also be included. The default constraints closure seems to get executed multiple times during Grails app startup.
I've tried a few approaches:
Use the platform-core plugin which this post talks about: How to configure a grails plugin from another grails plugin.
Problem there is similar: the Grails app's default constraints block is executed at least once before the plugin's doWithConfig begins to run.
(Hackish) Modify Grails app to include a FooConfig.groovy in its "locations", a file which exists in the plugin's grails-app/conf/ dir and thus accessible on the classpath (see below).
Problem: Hackish, still working through it but might be my only option.
grails.config.locations = ["classpath:FooConfig.class"] // Yes, *.class
Say I have a grails-master plugin that itself contains a (chained) "sub-plugin" called grails-widget. The master plugin pulls in the chained plugin like so:
// grails-master's BuildConfig.groovy:
plugins {
compile ':widget:1.0.5' // or whatever
}
This way, anytime a Grails app includes grails-master as a dependency, both master and chained plugins get pulled in.
Now let's say that the chained grails-widget plugin requires configuration. Let's say that if an app requires grails-widget directly (sans the master), then one must configure the plugin from inside the Grails app's Config.groovy like so:
grails.plugin.widget.fizz=1
grails.plugin.widget.buzz='YES'
... etc.
Here's what I'd like to accomplish, if at all possible:
If a Grails app just lists grails-master as a dependency, then the master pulls in grails-widget but provides default values for its fizz and buzz properties. This way, when the app declares grails-master, they do not need to define the above properties in its Config.groovy.
Again, if a Grails app just lists grails-master as a dependency, then although grails-master will (somehow, automagically) provide defaults for fizz and buzz, the app developer can still choose to define them in their app's Config.groovy. In this case, the app-defined values for fizz and buzz will override the defaults set back in grails-master.
Finally if the developer only lists grails-master as a dep, it would be nice to allow the app developer to disable the use of the (chained) grails-widget plugin altogether. Hence, anything the plugin does at app startup would not occur.
Are these items possible? If so, how could I accomplish them? If not, why?
Yes you can accomplish that. Default configs can be added when the master plugin is installed. Manually you can do as a post initialization configuration in doWithApplicationContext. But there is a convenient plugin-config plugin which can do that for you. Add this plugin to master plugin and set up default values for the widget plugin. The doc for plugin is self-explanatory. If not, I can add an example.
Any config provided by the plugin can be overridden in application's Config.groovy. Application's config is initialized in the end (after all plugins are initialized). So you can definitely override the default config which you would have setup from step 1 above.
You can exclude widget plugin from the master plugin when required, in application's BuildConfig.
Example:
//BuildConfig in application
plugins {
compile(':master:0.1') {
//exclusion based on some logic at build/compile time
if(some logic satisfied) {
excludes 'widget'
}
}
}
I am a total Grails noob trying to configure the db-reverse-engineer plugin for my first project. Documentation for the plugin indicates that I need to configure it, but I don't see where I am supposed to edit configuration.
Is there a configuration file in my project I need to edit? I have searched through the ./grails-app/conf folder for grails.plugin (the prefix for this plugin's configuration) and found nothing. An SO or Google search for how to configure grails plugins also returns void. I know this is a lame question, but how do I configure this plugin? Is there a UI I need to use, or are there files somewhere to edit?
You need to configure your database in grails-app/conf/DataSource.groovy. In particular, you'll need to provide the JDBC URL, the database dialect and the databases's username and password.
You'll also have to add some extra db-reverse-engineer configuration to grails-app/conf/Config.groovy. This file will already exist. Just append the new properties at the end.
Finally, run the reverse engineer script to generate your domain classes:
grails db-reverse-engineer
The right place for that would be the file grails-app/conf/Config.groovy.
Just add what you need at the bottom.