I created a Grails plugin and created a domain class in it called Config:
package com.company.common
class Config {
String defaultTimeZone
String defaultLanguage
}
In another Grails project, I'm including the plugin and I have this line in Bootstrap.groovy:
import com.company.common.Config
Every time I try to run the project though, I get this error:
C:\Code\grails-app\conf\BootStrap.groovy: 4: unable to resolve class com.company.common.Config
It works if I have the Config domain class in the same Grails project. It also seems to work if I rename it to something like ProjectConfig in the plugin project.
Does anyone know why I can't reference a domain class called Config in another project?
P.S. All the other domain classes in the plugin project can be accessed from the main Grails project, only the Config class gives me problems.
Grails plugins have specific files that are removed when packaging the plugin (so you can use them for testing). You can find the list here Grails Plugins #Creating and Installing Plugins. For convenience, here is the list:
grails-app/conf/BootStrap.groovy
grails-app/conf/BuildConfig.groovy (although it is used to generate dependencies.groovy)
grails-app/conf/Config.groovy
grails-app/conf/DataSource.groovy (and any other *DataSource.groovy)
grails-app/conf/UrlMappings.groovy
grails-app/conf/spring/resources.groovy
Everything within /web-app/WEB-INF
Everything within /web-app/plugins/**
Everything within /test/**
SCM management files within **/.svn/** and **/CVS/**
While this list does not include Config.groovy files in domain class folders, it might be caught by this. Would be worth checking if the Config.groovy file gets carried over to the packaged plugin, or if you can live with renaming the file, that would work as well.
Related
I need to customize the spring security LogoutController a little bit so I have copied the controller from the plugin to the same package location in my grails-app/controllers
The controller is used instead of the original one because the plugins are compiled first -> the original will be overriden.
Now my problem is that intellij 12.1.7 complains that the Class 'LogoutController' already exists in package 'grails.plugin.security' ... ofcourse :( but thats no error !
I could not find anything to hide that error in the validation setup.
Grails controllers do not take package into account: only 1 LoginContoller will be used regardless of the package: (default url mapping is /$controller/$action?/$id? no place for package there).
The same goes for Domain classes.
To override the LoginController from ANY plugin in your app you just need to define a LoginController in the app, no matter the package.
However, if you define it in the exact same package of the plugin you're creating a conflict that would need to be resolved by class loader precedence. That should be the same (app first) but I wouldn't take that for granted. Hence the error IntelliJ is showing.
I am currently working on creating a web service using Spring -WS.
I want to make the request reach my own Message Dispatcher Class. So I made the necessary configuration changes to web.xml and also my sping-congfig.xml file.
I am seeing an error when spring loads beans for my Message Dispatcher,
it tries to look for a properties file in my package which has the Dispatcher Class. for Example if my class is AccountMessageDispatcher, it looks for AccountMessageDispatcher.properties file in the package where I have created the class, I can get it running by keeping the properties file there, but I want to keep the properties file under my resources directory which has other property files needed by my application.
Can any one help me or point me in the right direction as to what I am doing wrong?
If we take a look to the default MessageDispatcher infrastructure, we'll that it reads appropriate proerties file - org.springframework.ws.server.MessageDispatcher.properties.
As you see this file is located at the same package as the original MessageDispatcher class.
According to your concern, you are right: that file should be located at the resources dir for sources. But if you use normal build system like Maven or Gradle, all your resources are packaged to the target jar alongside with classes.
To achieve your requirements you just need to create the same dir tree in the resources as your original AccountMessageDispatcher.
Actually any Java package is a dir in the end jar.
I am working with the Grails Authentication plugin and trying to add a domain class from the plugin into my GORM. I am able to use plugin objects in my application when importing them with, "import com.grailsrocks.authentication.AuthenticationUser", but getting "unable to resolve class" exception when trying to access my application objects from the plugin (I am trying to use the domain class "User" and my import command is "import blap.User" - package name is blap). Both import commands work from the shell, and the import statement is not triggering an error in STS.
I am new to grails, so I'm probably doing something very wrong. But, at this point I am running out of ideas, so any help would be greatly appreciated. Thanks!
Vitaly
While I haven't used the Grails Authentication plugin before, I don't think you should be modifying the plugin classes. In general, you should extend the plugin class you want to modify in your application and use your application class instead.
Actually, from reading the docs, it looks like you should use the event handling to modify the plugin behavior.
From the plugin docs:
The default AuthenticationUser domain class is minimal. If you want to change constraints or add fields (you may consider using a separate class instead for extra user data) you just redefine the onNewUserObject event and return your own instance of a domain class or similar wrapper around another authentication database such as LDAP
In my grails 1.3.7 project, I have put all of my classes in com.mycompany.myapp, as you do. So this goes for services, controllers, domain classes. I have a filter that goes in its own package. My app works fine.
However, when I run grails doc, grails decides to create two pages for every class:
one in its right comp.mycompany.myapp package that has all the right Groovy Doc
the other takes all the above classes and pretends as if those also live in the default package.
So, target/docs contains two directories: 'DefaultPackage' and 'com', with DefaultPackage holding a copy of everything that lives under com/
Consequently, my groovy doc looks messy because there is two copies for each class.
How can I solve this?
It has been documented as a bug at GRAILS-6605. There is no workaround listed there for the bug.
I too faced the same issue and so created a plugin "Grails Runtime Docs" ( http://grails.org/plugin/grails-runtime-docs ) that solves this issue and generates both Java and groovy docs properly only 1 copy per class. It's grails aware and categorizes the classes into Controllers, Commands, Domains, Services and Tag Libraries. The groovy documentation is actually generated from runtime so as to include the dynamic methods also, adding "Dynamic Method Summary" & "Dynamic Method Detail" in the generated html docs, that provide their source information. Hope you find it useful.
If I create a Grails app called a-b-c-d, doing a grails create-domain-class User will result in Grails creating a class User in the sub-directory grails-app/domain/a/b/c/d, giving it the package a.b.c.d. How do I prevent Grails from creating these package names?
You should definitely use packages, but you can customize the default package by changing the value of grails.project.groupId in Config.groovy. The default value is appName which is your application name, but you can change it to any value package, e.g. 'com.foo.bar'.
In addition you can specify the package when running a create script, and if you do want to create classes in the default package, you can use this syntax:
grails create-service .Person
and it won't use a package.
I have no idea, this sounds like a bug. There are two obvious workarounds
change your app to have a name without dashes
don't use the Grails commands create-domain-class, create-controller-class, etc. I never use these commands because they don't actually do anything other than creating the class (and a corresponding empty test class). Personally, I find it easier just to create the class myself than to run the Grails command
You can specify the package when you call the cli command...
grails create-domain-class your.package.name.User