My team suggests to modularize our current Grails project, so we experimented. We've started doing it through IntelliJ:
Projects > MyProject _right-click_ New > Module ..... create-app
Then we move each previously existing domain, controller, services, and view to their specific module.
When we run the project (through MyProject run-app -reloading), the pages that previously were accessible returns error 404. Now of course, we believe that is because the project directory is restructured. We attempt to access those pages from this old url:
http://localhost:8080/MyProject/someController
to this new url, assuming that it only needs to append the module name
http://localhost:8080/MyProject/the-new-module-name/someController
^ ^ ^ ^ ^ ^ ^ ^ ^ ^
But it still doesn't work. How do we suppose to run the project along with it's module and how can we access them? Do we need to configure some .config and .property files?
This is what the new project directory looks like:
MyProject
+.idea
+ grails-app
+ lib
.
.
.
- the-new-module
+.idea
+ grails-app
+ lib
.
.
.
+ web-app
+ wrapper
.
.
.
+ web-app
+ wrapper
edit: The reason the team wants to implement this "modular" approach is that our current Grails project can still be subdivided further into smaller, independent projects (for maintainability, etc.). Now, we have manage to create (and run) these smaller projects. The problem arises on consolidating these smaller pieces. So the task is to create a parent Grails project (is that even possible).
It would appear you're making the assumption that InteliJ "modules" are something that Grails understands. It does not.
The correct approach to making a modular Grails application is "plugins". Grails has great support for creating your own plugins. You can even create inline plugins which greatly speed up development. I highly recommend you read the official documentation regarding plugin creation and use in your Grails application.
Keep in mind that your plugin can have almost all the same artifacts as your application (services, domain classes, controllers, GSPs, etc.) but will appear under the same application as if the application using the plugin was providing the artifacts.
For example, if you have the BookController in your plugin it will have the same URL mapping as if the controller were a part of your base application. You indicate in your question that you wish to have different URLs for these controllers which are provided by your plugins. If that's the case then you need to namespace your controllers. You can read more about that in the official documentation too.
Update
In order to help visualize how plugins work with modular Grails applications:
/~/MyApp
/~/PluginA
/~/PluginB
MyApp is the main application (created using grails create-app). It has it's own functionality and includes both PluginA and PluginB (both created using grails create-plugin) to add their functionality to itself. You have the option of using inline plugins or even packaging the plugins and publishing them to your own internal repository for use by other applications (MyApp in this case). Notice that all three parts of this are separate. They can be modified independently of one another, versioned in your source control, managed, developed, etc.
Related
I have a rather monolithic Grails 2 application that I am attempting to upgrade to Grails 3 (specifically 3.2.7) and refactor into a set of plugins - the current app uses various services on Amazon AWS, I want to refactor it so I can more easily switch to Microsoft Azure or OpenStack.
At present, the big app uses various plugins including Spring Security UI, and the app overrides some of the GSP views from the plugin with its own. In the refactored scenario I have the main app (which will implement the AWS-specific bits), depending on a "core" plugin (with the cloud-agnostic functions) which in turn depends on spring-security-ui. The problem I'm having is that when I put my custom auth.gsp view in the "core" plugin rather than in the top-level app, it no longer overrides the s2ui version of the same view. If I copy the "core" plugin's auth.gsp to the same location in the top-level app, it overrides correctly.
In general, if I have app depends-on plugin1 depends-on plugin2, is there a way to ensure that when I run the app, views provided by plugin1 take precedence over the same views provided by plugin2?
The core plugin will need to specify it should be loaded after spring security ui. You can do that with:
def loadAfter = ['springSecurityUi']
This is documented here: http://docs.grails.org/latest/guide/plugins.html#understandingPluginLoadOrder
I have a fairly complicated grails plugin dependency structure within my project and I am having problems overriding classes from the security plugin.
My structure is a little something like this:
Web App
|_ Audit Plugin
|_ Spring Security Core Plugin
|_ Security Wrapper Plugin
|_ Audit Plugin
|_ Spring Security Core Plugin
The reason it is like this is audit is shared between some apps which have the security wrapper, and some what don't, which is why it pulls in Security-Core (it needs at least the ability to get the current principal).
Similarly the wrapper is shared between multiple web apps therefore we put it in a plugin. My problem comes after upgrading Spring-Security-Core to version 2.
My wrapper has a customer auth.gsp and LoginController.groovy. In the older version of security this was fine, as the plugin templated those and made them available in the source of the installing plugin.
However now these files are internal to the plugin, and although I know you can override them within the main app, when trying to override them within another plugin I get some bizarre results.
The Spring-Security-Core version of the login page always overrides my custom login page. I cannot get mine to take precedence.
The second problem is that the LoginController.groovy from the Spring-Security-Core plugin sometimes takes precedence over my one from the wrapper. It seems almost random between builds as to which one will be in use.
Is there any correct way to go about making sure my views and controllers take precedence?
OK playing around with things I found a solution that seems to work for me:
Firstly I couldn't change the order in which the plugins load because the security wrapper does a lot with spring beans and it has to load after the core plugin for this to work. So after a bit of digging in the (DefaultSecurityConfig.groovy) I noticed that you can set the following properties:
grails.plugin.springsecurity.failureHandler.defaultFailureUrl = '/login/authfail? login_error=1'
grails.plugin.springsecurity.failureHandler.ajaxAuthFailUrl = '/login/authfail?ajax=true'
grails.plugin.springsecurity.auth.loginFormUrl = '/login/auth'
So I created a custom controller and login page which have a different name to the ones use in the core plugin and changed these properties to point to my locations.
To neaten this up, in the UrlMappings for the wrapper (named: SecWrapperUrlMappings) I put a mapping from /login/** to /seclogin/**.
Make sure that these new locations aren't locked down so that people can access them and that seems to work well. I now reliable know, whichever order they load in my login page and login controller are used.
In Grails-4.013 and spring-security-core-4.0.4, I did the following trick.
In my custom plugin instead of LoginController and LogoutController I named them as SigninController and SignoutController respectively. And in UrlMappings.groovy of App mapped them like..
static mappings = {
"/login/$action?"(controller: "signin")
"/logout/$action?"(controller: "signout")
....
....
}
I used Grails recently, and added Grails plugin for JQuery, but I don't think it did anything more than just copy some jQuery files over.
So far, I have seen info only on 'how to install and use' plugins...but I can't find anything that describes the concept of a plugin.
Can somebody please tell me, what is a Grails Plugin? And what does it mean to 'Install' a plugin?
A Grails plugin is (or should be) a self-contained bundle of functionality that can be installed into a Grails application. When a Grails plugin is installed, it can do any of the following:
define additional Spring beans
modify the generated web.xml
add new methods to the application's artefacts (controllers, domain classes, services, etc.)
provide new tag libraries
make additional resources and classes available to the application
provide new Grails commands
For example, when you install the JQuery plugin
the JQuery JavaScript files are added to the application
a new Grails tag <jq:jquery> is added to the application
a new Grails command grails install-plugin jquery is added to the application
When you install a Grails plugin, that plugin's functionality is made available to the installing application. However, the plugin itself is not actually copied into the application, only the plugin name and version is added to the application's application.properties file. The plugin itself is downloaded to $HOME/.grails and the application loads it from there.
The structure of a Grails plugin project is identical to that of a Grails application, with the exception of a configuration file (known as a plugin descriptor) that is included in a plugin's root directory.
Well, a Grails plugin is some piece of software that extends the frameworks funcionalities in some manner. Generally, installing a plugin in Grails means copying it to your Grails folder, so projects can refer to it and Grails will know where to find it.
Grails plugins have this folder structure:
grails-app
controllers
domain
taglib
service
etc
lib
src
java
groovy
web-app
js
css
So anything it has there will also be available to the application that uses it. For example, the Searchable plugin has a service class which you can use to perform advanced searchs in your own domain classes .
The jQuery plugin you mentioned has the jQuery .js file, and a tag to include that file.
For information on creating plugins, see http://grails.org/doc/latest/guide/12.%20Plug-ins.html
A plugin is just a set of functionality around a desired purpose. So the Spring Security plugin provides a way to lock down your app, assign roles to users, restrict access, whatever. The Searchable plugin allows you to integrate advanced searching into your app. There are lots of plugins
The point is to provide useful functionality so that you don't have to implement hard things yourself. Someone did something useful, and they wanted to contribute back to the community, so they organized their functionality and made it available.
A plugin is code and configuration, like any functionality you would implement yourself.
There is some documentation here: http://grails.org/doc/latest/ref/Plug-ins/Usage.html
What is the recommended approach when an application Controller name conflicts with the name of a plugin's Controller?
I've seen these Grails JIRAs:
GRAILS-4240
GRAILS-1243
...and Burt Beckwith's replies to these two threads imply that the only recourse is to rename one of the Controllers (presumably the application Controller since hacking plugin code is not desirable)
How to use the package name to differentiate between classes in grails?
How to extend/override controller actions of plugins?
However, Burt's own spring-security-ui plugin advocates the exact approach of naming an application Controller the same as a plugin Controller - see spring-security-ui docs.
This approach actually seems to work in both development mode (grails run-app) and when the app is deployed as a WAR. So can this functionality be depended on? If so, what is the Controller conflict resolution rule? The grails docs do not make any mention of it. Perhasps Burt can share his insight?
Having a "plugin" architecture like grails' without even a basic namespacing facility to handle conflicts like this seems pretty broken to me...
The problem is that while you can use packages for any artifact, the convention for controllers is to remove the package and "Controller" to create URLs, e.g. PersonController -> /appname/person/action_name. So in effect everything gets flattened.
In 1.2 and more so in 1.3 things were changed so plugins are compiled separately from application code (and are compiled first) and this gives you the opportunity to replace a plugin artifact with the application's version. Since you shouldn't edit plugin code, this gives you the flexibility to extend or replace a plugin artifact just by using the same name.
I tend to use UrlMappings to get around stuff like this when there are two similarly named controllers. For example say you have an admin UserController that allows low-level CRUD actions and a regular UserController that users work with. I'd name the admin controller AdminUserController and map it to /admin/user/* and leave UserController as is. The admin GSPs will be in views/adminUser and the others will be in views/user so there's no conflict there. This has the added benefit of being able to easily secure - map /admin/** -> ROLE_ADMIN. The conventions are convenient, but this is a simple configuration step that solves this issue for me.
The good news is that GRAILS-1243 will definitely be implemented in 2.0 and possibly in 1.4. And the plugin that Kim Betti references in the comments of GRAILS-1243 looks interesting.
I'm writing a Grails app which I'd like 3rd parties to augment at runtime. Ideally they would be able to add a JAR/WAR to the webapp directory which contains new domain, controller and service classes, new views, and other content.
Is there a simple way to do this within grails? Would it be simplest to create a startup script which copies the new classes etc. into the relevant directories and then updates grails.xml and web.xml?
You will be able to do this in version 2 of grails in which plugins will be also OSGI plugins http://jira.codehaus.org/browse/GRAILS/fixforversion/15421
It seems that the Grails plugins will actually fit quite well for this: http://www.grails.org/Understanding+Plugins
A plugin can do just about anything... One thing a plugin cannot do though is modify the web-app/WEB-INF/web.xml or web-app/WEB-INF/applicationContext.xml files. A plugin can participate in web.xml generation, but not modify the file or provide a replacement. A plugin can NEVER change the applicationContext.xml file, but can provide runtime bean definitions