Regarding my question on twitter about completely disabling the creation of stacktrace.log from a Grails application in production mode, here is my answer:
environments {
production {
log4j = {
appenders {
null name:'stacktrace'
}
}
}
development {
}
}Be careful: This overwrites all other log4j closures that are made outside the environment specific settings. I found no solution for that.
Background: One of my Grails 1.1 app fails to start on a Tomcat application container deployed on an Oracle Enterprise Linux server because it fails to create the stacktrace.log.
What annoyed me is that i needed to dig around in the Grails source code to find the answer to my question in “src/groovy/org/codehaus/groovy/grails/plugins/logging/Log4jConfig.groovy” within the method “createFullstackTraceAppender()”. Should be stated in the documentation (perfect place here).
Edit: If your Grails 1.1 still fails to start(*) look out for xercesImpl.jar and xml-apis.jar or similar somewhere in your Tomcat 5 directory. These are some kind of Java 1.4 compatibility layers which break things in Grails 1.1. Oracle puts these into common/endorsed. After removing them, everything went fine.
(*) Exception was:
java.lang.RuntimeException: XPathFactory#newInstance() failed to create an XPathFactory for the default object model:
http://java.sun.com/jaxp/xpath/dom with the XPathFactoryConfigurationException: javax.xml.xpath.XPathFactoryConfigurationException:
No XPathFctory implementation found for the object model: http://java.sun.com/jaxp/xpath/dom
Share This
The last Passenger update brought some good explanation off the problems regarding Passenger and memcache-client (see here).
Smart spawning of Passenger processes creates shared file descriptors. As the connections to memcached are sockets they are shared as well so data on them gets corrupted which is explained very nicely in the Passenger documentation: Example 1: Memcached connection sharing (harmful).
The solution presented there works like a charm. The reestablish_connection_to_memcached line is actually not more than CACHE.reset where CACHE is the reference to the memcache connection.
After that change, spawning methods smart-lv2 and smart will work in connection with environment.rb configured memcache connections.
Edit: As requested in the comments, a little example:
memcache_options = {
:c_threshold => 10000,
:compression => true,
:debug => false,
:namespace => 'some_ns',
:readonly => false,
:urlencode => false
}
CACHE = MemCache.new memcache_options
CACHE.servers = '127.0.0.1:11211'
begin
PhusionPassenger.on_event(:starting_worker_process) do |forked|
if forked
# We're in smart spawning mode, so...
# Close duplicated memcached connections - they will open themselves
CACHE.reset
end
end
# In case you're not running under Passenger (i.e. devmode with mongrel)
rescue NameError => error
endIn this case, CACHE is the global constant that i use to access my memcache-client.
I guess you’ll need to do the same with the global Rails.cache object, but i’m not sure. Anyway, the above solution works for me.
Share This
Some things are not really different in Rails and Grails world. The pendant to Rails’ respond_to method is Grails withFormat block.
Both are supposed to render a different content type as requested according to the accept header and and the format parameter.
And both fail to some extend with Internet Explorer 5.5 to 7.0. For a longer explanation see my post on respond_to linked above. In short: First visit always gave me the an Excel File, all subsequent visits the intended html page.
I used nearly the exact solution within Grails 1.0.4 as in Rails:
withFormat {
xls {
// Same crap with IE 6/7 as with rails, compared to
// http://info.michael-simons.eu/2007/08/06/rails-respond_to-method/
if(params.format == 'xls') {
def df = new SimpleDateFormat("yyyy-MM-dd")
def report = ExcelReport.findById(params.reportId)
if(report == null)
report = ExcelReport.findByBezeichnung('Absatzprognose')
response.contentType = 'application/vnd.ms-excel'
response.setHeader("content-disposition", "attachment;filename=some_filenname.xls")
excelService.runExcelReport(
report.bezeichnung,
"some_parameter",
response.outputStream
)
return
}
}
}Grails 1.1 seems to have fixed some issues on this case and a default or empty html {} block in front of any other format like so will do the trick:
withFormat {
html {
// depending on your needs
}
xls {
// funny excel stuff
}
}Share This