4

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...

Community
  • 1
  • 1
Eric
  • 836
  • 1
  • 11
  • 18

1 Answers1

6

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.

Burt Beckwith
  • 75,342
  • 5
  • 143
  • 156
  • Thanks Burt! I'm not sure I fully understand how the compile ordering comes in to play. Since my FooController and the plugin's FooController are in different packages, neither overwrites the other's .class file. Both FooController.class files are in the WAR. So it seems that Grails has some lookup logic that prefers the application's to the plugin's... – Eric Mar 09 '11 at 13:12
  • Right, they're compiled to different folders, so there's no .class file collision. At startup the process that finds artifacts finds the plugin's artifact first, but then the application's artifact replaces it because it has the same 'artifact' name. – Burt Beckwith Mar 09 '11 at 15:44