In grails 2.4.3 it is possible to access a private field in a class outside from the class. See http://refaktor.blogspot.co.at/2012/07/private-fields-and-methods-are-not.html or https://issues.apache.org/jira/browse/GROOVY-1875.
Is this issue fixed in Grails 3.x? Because we plan to upgrade to the new version and some code access privates already. So I want to know if I have to check every access for a private variable.
This issue has nothing to do with Grails and is specific to the Groovy programming language.
Related
I want to migrate an application from grails 2.4.4 to grails 3.3.9.
As the structure of the conf directory in grails 2.x is completely different from 3.x, there is no config.groovy in 3.x anymore. In config.groovy of 2.x I used to define lists of constants for my select boxes like:
metals=['au','ag','pl']
and I accessed them via
static List getMetals() {
grails.util.Holders.config.metals
}
in my groovy code.
What is the corresponding way in 3.x?
I would start by checking out the upgrade guides:
http://docs.grails.org/latest/guide/upgrading.html
http://docs.grails.org/3.2.0/guide/upgrading.html#upgrading2x
config.groovy, by default becomes application.yml, but you can convert that to application.groovy, and there is a script in the external config plugin that will help with that:
http://plugins.grails.org/plugin/grails/external-config
In general it is conserdered back practice to use the holders, it would be better to use either an injected bean/service
GrailsApplication grailsApplication
grailsApplication.config.etc
Or wire in a bean using resources. The only reason to use holders is in another object that is outside of grails, that for some reason, you can't wire up as a bean. In that cases there is now a Holders class, that you can get the config from. Here's some other ways to get at the config from an OCI blog:
http://grailsblog.objectcomputing.com/posts/2016/08/31/retrieving-config-values.html
In my custom Grails plugin, how can I set up a JSON view for a non-domain class and get client apps to use it by default?
I have a view file in the plugin:
/views/com/mycompany/myplugin/myclass/_myClass.gson
When I do grails install, I can see that this .gson file is in the generated JAR. However, the client app is not using it.
What can I do to make it work?
Are there any settings or steps that can make troubleshooting easier?
I am using Grails 3.2.4.
Update:
When I copy the view into a client app, using the exact same path, the view is getting invoked. It's only when the view is defined in the plugin that the view cannot be found.
The framework seems to be trying to look up the plugin as a class from the classloader:
myclientproject_com_mycompany_myplugin_myclass__myClass_gson
How do I get my plugin to add this class to the classpath?
For my use case, what I actually needed was a custom converter.
See:
In JSON views, how do I flatten an object out as a single string?
This obviated the need for my plugin to publish a view.
I have multiple plugins with Grails domain classes that are stored in separate databases. I want to be able to configure within the dependent project what sources each class comes from. It seems like a similar question is here:
Grails changing datasource at runtime
Is it still not possible to add additionaly sources to a class at runtime? And, I don't necessarily need to do it at runtime either. Just configure the class in the dependent Grails application. The method for setting this up (http://www.grails.org/doc/2.2.1/guide/conf.html#multipleDatasources) requires direct access to the class definitions, and I'd rather avoid having to do that.
Plugins in Grails are great method to modularise an application.The documentation suggest to override the artifacts from the plugin in the application, which uses this plugin.
Is it realy the best approach?
Let's describe it by example: There is a domain class "org.User" defined in the plugin. The application overrides this domain class. If I use "grails run-app" then there are no warnings and it works. But Eclipse (GGTS) complains about "Invalid duplicate class definition of class org.User". For some developers it wouldn't matter, but I like the IDE helping on coding by stuf like "autocomplete".
At the end both classes are compiled an put on the java class loader. The application version of the class is loaded before the version of the plugin. The class resolver finds it first and that's why it works. Please correct me if I'm wrong at this point. Is it realy a good idea to have two versions of a class in one class loader?
What are the alternatives?
You can do like Spring Security Core plugin does, provide the User class as a template, so your application that use this plugin can choose between creating his own class or installing your default User class.
The plugin user template is here, and the script responsible to create this in the application is here.
You will need also a config value to know the class to use, and use it dynamic.
P.S: there are good security plugins like Shiro and Spring Security, maybe it's easier to check them instead of create your own.
I cite from mybatis plugin documentation:
"When working with MyBatis plugin your "Domain" classes should be
located in src/groovy and not in grails-app/domain. This is necessary
to avoid conflict with GROM since MyBatis plugin can coexist with
existing GORM Domain classes."
So where should the validation and constraints be located, when I want to use grails with MyBatis plugin ?
You can add a #Validateable annotation to any Groovy class in Grails, and you will be able to validate it... The Plugin currently doesn't check for any validation errors so you will have to implement that code yourself.
From official Grails documentation:
Classes which define the static constraints property and are annotated
with #Validateable can be made validateable by the framework
http://grails.org/doc/2.1.0/guide/validation.html#validationNonDomainAndCommandObjectClasses
You could even write a custom MyBatis Interceptor (see https://github.com/fzilic/Grails-MyBatis/blob/master/src/groovy/org/grails/plugins/mybatis/locking/OptimisticLockingInterceptor.groovy) and register it after the SqlSession is created...
Currently the MyBatis plugin doesn't support registering custom Interceptors in it's configuration, but they could be added to the interceptor chain
def factory = GrailsApplication.mainContext.getBean("sqlSessionFactoryBean_dataSource")
factory.configuration.interceptorChain.addInterceptor(Interceptor)
Support for this might be added in future versions.