While I understand that it is not "best practice", I have a lot of legacy plugins that I am upgrading to Grails 3, and I need to set their GSP encoding back to the old default of "none" (because everything is already encoded where it needs to be, and we expect non-encoded data elsewhere.) Unfortunately, this appears to not work per the documentation.
The Grails 3.2.11 docs say:
Per Plugin Encoding
Grails also features the ability to control the codecs used on a per plugin basis. For example if you have a plugin named foo installed, then placing the following configuration in your application.groovy will disable encoding for only the foo plugin
foo.grails.views.gsp.codecs.expression = "none"
This did not work, using Grails 3.2.11. Encoding is still "html".
Other things I tried, that also did not work:
Just changing the plugin's application.yml from the default values (this seems like it would be ideal to me, and was what I originally expected would control the plugin encoding)
Same line, in runtime.groovy
Same line, in the plugin's plugin.groovy
Same concept with the prefix, in both the application's and the plugin's application.yml
Changes per suggestions in How can I exclude a plugin from grails default gsp encoding?
I'm perfectly willing to write this up as a Grails bug, but figured I would ask here first in case somebody else has already solved this!
Thanks in advance!
See linked grails issue for answer; short version is that:
all codecs must be valid, or defaults are used due to exception thrown in codec processing
plugins should be cleaned before publishing, or precompiled gsps may still use previous codecs
Related
In Grails 2 we used the "External configuration plugin", which included the method checkNow() for checking and refreshing values from an external config file.
Does it exist a simple approach for doing something similar in Grails 4+? I have seen references to Spring Cloud Config Server, but it seems a bit overkill for me. All I really want to do is be able to (now and then) update a config value in runtime. It could also be purely by a few lines of code, and does not have to originate from changes in the config file. This would avoid having to restart our server for minor changes in config. Thanks!
I'm replying to myself with a ridiculously simple answer: "just change it". Using the console plugin (or any other form of code execution), I can just assign grailsApplication.config.any.property a new value. It won't persist and it won't update any listeners or anything. But it is a glaringly obvious solution that I just assumed wouldn't work due to the getProperty() calls (I interpreted the name as reading from file) and googled discussions about Spring Cloud Config.
So, move on... nothing to see here. Just mild embarrassment :-P
As we know by default logging in Grails 3.0 is handled by the Logback logging framework and can be configured with the grails-app/conf/logback.groovy file. The good part of this was that the configuration inside this file was applicable for the Logback and Log4j implementations (tested successfully in Grails 3.1.2). After we migrated to use Grails 3.2.8 from Grails 3.1.2 (as I said before), it seems that the configuration inside the logback.groovy file is not used by the Log4j and it should be configured in other way - at runtime.
I made a deep research in this to ensure that this is really the way it is configured now and it seems that if I am using the default Log4j logging:
org.apache.log4j.Logger.getLogger("name").info("TEST");
is not working at all. To make the information populated into the output log file, I should use the default SLF4J API:
org.slf4j.LoggerFactory.getLogger("name").info("TEST");
The problem here is because that we have a lot of places in the code where the logging is implemented using Log4j approach and now - nothing is written in the log file.
So I have two questions here. The first one - is this the exact way how Grails implemented this behavior (as nothing is mentioned in the official documentation - Grails 3.2.8 Documentation). The second one - is the XML or RUNTIME configurations are the best way to configure the Log4j, so use it as before. If yes - the bad thing here is that we should maintain two same configurations at a time. Is there any other way to configure the Log4j to use the same configuration as the Grails Logger.
P.S. There is no need to publish any code, as all are just default configurations.
Thanks a lot!
appender('STDOUT', ConsoleAppender) {
encoder(PatternLayoutEncoder) {
charset = Charset.forName('UTF-8')
}
}
root(ERROR, ['STDOUT'])
logger("<package_name>", DEBUG)
List artifacts = ["conf", "controllers", "domain", "init"]
artifacts.each { artifact ->
logger("grails.app.${artifact}.<package_name>", DEBUG)
}
After writing this, you can add logger for debugging in any artifacts mentioned above like:
log.debug "Any Message"
For more setting you can read here: https://logback.qos.ch/manual/groovy.html
I was hopping to have an easy way to customize the display behavior of the Grails fields plugin after reading its docs, but I just realized that it demands an enormous effort as there is no available templates to start from.
I can see the display functionality is hard-coded in FormFieldsTagLib (from methods like renderDefaultInput() ) but I think it is imperative to have the templates themselves (or a way to generate them, somewhat like generating static scaffolding in Grails).
I can see no consistent (and reasonable) way to customize display behaviors for the Grails fields plugin without that. Am I missing something?
Imagine the use case where someone wants to change the boolean default rendering just to display the field label after (and not before) the checkbox, and keep it available to all the boolean fields within its application. Which concerns will he need to handle regarding if the field is required, has errors, prefix and so on? When all he needed was just moving two divs around.
Grails version: 2.5.4, fields-plugin version: 1.5.1
You aren't missing something. You'd have to re-create the existing implementation of each field type rendering in a template for use with the plugin. There isn't a way to generate a file to start with (like scaffolding).
I won't bore you with the historical reason as to why this is the case, but if you do create a set of base templates it would be a good idea to contribute back to the plugin.
I had an issue with the <f:table> tag, and found this post, which led me to find the base or default template inside the plugin repo.
Take a look at
https://github.com/grails3-plugins/fields/tree/master/grails-app/views
That may help you finding some default templates, along with the official doc and this answer on where to put the override.
Hope it helps you.
It should be possible to configure freemarker to use the old #-less syntax.
However, to give users time to prepare for this change, in FreeMarker 2.1 and 2.2 the usage of # is optional, unless the programmer enables strict syntax mode in the FreeMarker configuration by calling setStrictSyntaxMode(true) on Configuration. In fact, we strongly recommend this to programmers. Starting from some later release this setting will be initially set to true. Also, you can specify if you want to use strict syntax or old syntax in the template files with the ftl directive.
http://freemarker.org/docs/ref_depr_oldsyntax.html
How can I configure the fmpp preprocessor to use this old syntax with the Ant integration? Is there a setting or how can one call setStrictSyntaxMode(false)?
I am grateful for any assistance!
It seems you can't... it's not exposed through FMPP's setting API. If it's any consolation, the new syntax is more practical, because it catches more typos, and because the Eclipse plugin supports it. So if you have some old templates, certainly it's better to take that 15 minutes and search-and-replace the FTL tags with the # version.
I was able to solve this by adding an "oldSyntax" Setting myself using the "setOldTemplateSyntax" method that is offered by the Engine.
https://github.com/freemarker/fmpp/issues/20
I have 1.3.2 installed. My investigations found this in scripts/DbmDiff.groovy:
// TODO this will fail with JNDI or encryption codec
buildOtherDatabase = { String otherEnv ->
Searching the web lead me to this:
https://github.com/grails-plugins/grails-database-migration/commit/ac38a7310fe48ba7b5c4dda4d6e30dd8040dbeb6
which is code for DbmDiff.groovy, but in spite of the same TODO comment, appears to handle jndi.
Does this mean that a 1.3.3 is coming soon with jndi support? If so, then I can work around for a while using a temporary env using urls etc.
Regards, John
I'm not sure when 1.3.3 will be released since this is the only fix so far. It shouldn't be too soon though. Until then you can copy the current script to your application's scripts folder. Then you run grails dbm-diff Grails will ask you which of the two scripts to run.