I have been trying many solutions:
app.vaadin.productionMode: "true"
app.vaadin.productionMode: true
vaadin.servlet.productionMode: true
But nothing is working, I always get this msg in console:
===========================================================
Vaadin is running in DEBUG MODE.
Add productionMode=true to web.xml to disable debug features.
===========================================================
What is the good way of going production mode with spring boot (in a yml file)?
This is the correct property name, which enables production mode on Vaadin 10 (and 11):
vaadin.productionMode: true
Related
We have a legacy application running on Oracle Application Server J2EE 10g 10.1.3.5.0 using OC4J containers. To clear a Veracode dynamic scan flaw CWE ID-402 (and for best practice) we need to set the HttpOnly flag on our JSESSIONID cookies. We found, albeit scant, documentation for a system property:
-Dhttp.response.httponly=true
That supposedly supports this. (Some details on all supported properties here, although you may want to run it through a translator: https://volbers.wordpress.com/2011/06/24/secrets-of-the-oc4j/)
What we found, however, is that while this property works in a stand-alone OC4J instance (e.g., running in Eclipse), it does not work when deployed under OAS/OPMN. We even tried using reflection to lookup the Evermind OC4JProperty for HTTP_RESPONSE_HTTPONLY and were able to set it to true programmatically. However, the same behaviors ensued: Something is ignoring that property when running in the deployed container.
Does anyone know how to make this work in a deployed environment?
Just for context, here is OC4J's own description of this property:
% java -jar /oas/j2ee/home/oc4j.jar -describeProperty http.response.httponly
Property name: http.response.httponly
Description: Used to prevent cross-site scripting attack
Default value: false
Primitive type: Boolean
Deprecated: false
Log value change: false
Is static: false
Try adding the following to your orion-web.xml
<session-tracking cookie-path="/pathtoyourapp; HttpOnly"/>
I've configured my Grails app to read the log4j config from /conf/log4j.properties file instead of the more usual DSL in Config.groovy, by adding the following Spring bean:
log4jConfigurer(MethodInvokingFactoryBean) {
targetClass = "org.springframework.util.Log4jConfigurer"
targetMethod = "initLogging"
arguments = ["/conf/log4j.properties", 1000 * 60] // 2nd arg is refresh interval in ms
}
My goal is to log all the classes in the app itself at the DEBUG level, and all others at the WARN level. /conf/log4j.properties contains the following:
log4j.logger.com.myapp=DEBUG, CONSOLE
log4j.logger.grails.app=DEBUG, CONSOLE
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%-5p myapp %c{3} %d{HH:mm:ss,SSS} %t : %m%n
It seems the namespace com.myapp is used for regular classes in my app (e.g. those under src/groovy), whereas the namespace grails.app is used for Grails artefacts (controllers, services, taglibs, etc.). However the grails.app namespace also includes artefacts from plugins, which I don't want to log at the DEBUG level.
Is there a way to enable DEBUG logging only for the classes in my application?
You append your package unto the grails.app.controllers to get just your application.
info 'grails.app.controllers.mypackage'
Adding the following solved the problem
log4j.logger.grails.app.conf.com.myapp=DEBUG, CONSOLE
log4j.logger.grails.app.filters.com.myapp=DEBUG, CONSOLE
log4j.logger.grails.app.taglib.com.myapp=DEBUG, CONSOLE
log4j.logger.grails.app.services.com.myapp=DEBUG, CONSOLE
log4j.logger.grails.app.controllers.com.myapp=DEBUG, CONSOLE
log4j.logger.grails.app.domain.com.myapp=DEBUG, CONSOLE
Presumably if a Grails app has other types of artefacts that you want to log at the DEBUG level, an additional logger should be configured for each one.
Are there any ideas how I can setup my Dart app to use different settings in debug mode (running in Dartium) and production mode?
For example, I'm using PouchDb in my app, that replicates the database to a particular CouchDb instance, given by an url: db.replicateTo(url);
In debug mode, I would like to use another CouchDb instance (another url) than in production mode.
So, are there any ideas or approaches, to use different setups in both modes?
this works since a short while:
transformers: # or dev_transformers
- $dart2js:
environment: { PROD: "true" }
access it from the code like
String.fromEnvironment()
main() {
print('PROD: ${const String.fromEnvironment('PROD')}');
// works in the browser
// prints 'PROD: null' in Dartium
// prints 'PROD: true' in Chrome
}
see also
Configuring the Built-in dart2js Transformer
How to achieve precompiler directive like functionality
https://github.com/dart-lang/pub/issues/798
http://blog.sethladd.com/2013/12/compile-time-dead-code-elimination-with.html
https://api.dartlang.org/stable/1.22.0/dart-core/bool/bool.fromEnvironment.html
dart check if is building
So I basically do this.
OObjectDatabaseTx result = OObjectDatabasePool.global().acquire( "local:orientdb", "admin", "admin");
//dostuff
result.close;
The problem is that when I redeploy my webapp (without restarting the Java EE container) I get the folling error:
com.orientechnologies.orient.core.exception.OStorageException: Cannot open local storage 'orientdb' with mode=rw
which I interpret to mean "Tomcat still has a filelock from the last app".
So my question is how do I cleanly exit in this scenario? I've tried:
OObjectDatabasePool.global().close()
and
new OObjectDatabaseTx("local:orientdb").close()
but neither seem to work. Any ideas? The documentation isn't exactly clear on this issue.
Set the property "storage.keepOpen" to false:
java ... -Dstorage.keepOpen=false ...
or via Java code:
OGlobalConfiguration.STORAGE_KEEP_OPEN.setValue( false );
So I'm getting page load times in the range of 30-45 seconds.
Some history:
This was not always the case for this project. This project is in production so I haven't really touched the code in a while. I noticed it started happening the last time I was updating the code. I don't recall anything specific that I changed that should have anything to do with the problem. I have other projects that are running with the same Grails versions with no problem.
I think it started happening in 2.2.3. I am now running 2.2.4.
I am using x64 JDK 1.7.0_25, Windows 7 x64.
I'm not sure what else to put here that would be relevant. Any assistance is appreciated!
Edit: running with -noreloading has no effect.
Edit2: I've tried deleting my .grails folder entirely, running clean, and deleting my target folder and stacktrace log.
Edit3: It does seem that the amount of time it takes is dependent on the amount of data displayed/read. Small pages take 3-4 seconds. Medium pages 10-12 seconds...
Edit4: I'm running it via IntelliJ IDEA 12.1.4 x64 (idea64.exe). I've also tried it outside of IntelliJ with the same results.
Edit5: The database is Oracle enterprise that supports the entire company. It is managed by full time adminstrators. This isn't a MySQL server on my local machine.
Edit6: The application also functions normally when deployed in TEST (test war), but still is slow when ran with test run-app.
Starting to get somewhere:
I downloaded JDK 1.7.21 and ran the app with that and it started working no problem! I then ran clean which triggered a recompile and it stopped working... grr
Now with 1.7.21 still active, I tried -noreloading and it works!
Annnd... now it works even if I don't use -noreloading..........
I've gone back to 1.7.25.. ran clean, and it works. Sooooooo yeah... explain that.
And now it doesn't anymore.
This is under Linux but will maybe useful:
If you are running the code within an IDE:
ps auwx|grep java
-Dgrails.console.class=grails.build.logging.GrailsEclipseConsole -Dosgi.requiredJavaVersion=1.6 -Xms40m -Xmx768m -XX:MaxPermSize=256m -
As you can see the memory settings Xms and Xmx are quite low...
In your IDE there should be an INI file:
more STS.ini
1 -vm
2 /usr/lib/jvm/java-6-openjdk-amd64/bin/java
3 -startup
4 plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar
5 --launcher.library
6 plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.200.v20120913-144807
7 -product
8 org.springsource.sts.ide
9 --launcher.defaultAction
10 openFile
11 -vmargs
12 -Dgrails.console.enable.interactive=false
13 -Dgrails.console.enable.terminal=false
14 -Djline.terminal=jline.UnsupportedTerminal
15 -Dgrails.console.class=grails.build.logging.GrailsEclipseConsole
16 -Dosgi.requiredJavaVersion=1.6
17 -Xms40m
18 -Xmx768m
19 -XX:MaxPermSize=256m
You can up these value and try restarting your IDE...
I would also suggest you run something like nmon before/during and monitor whilst the code is running and monitor disk/cpu/network throughputs.
You may find you are hammering your dev box which is causing the issue.
If the production is fine I really don't see what the problem is..
E2A Ahhh forgot it was under windows so no nmon for windblows but hey not that I tried it - http://sourceforge.net/projects/jnmonanalyser/
E2A again:
1. Enable DataSource.groovy debugging:
dataSource {
pooled = true
driverClassName ="com.mysql.jdbc.Driver"
username = "aaa"
password = "aaaa"
//SQL Logging - refer to Config.groovy at hibernate.sql now
logSql=true
...
config.groovy - this will stop your app from running if you have issues with lets say records you are trying to add in your BootStrap
// Return error when it fails
//grails.gorm.failOnError=true
Enable log4j and use this or part of it:
// log4j configuration
log4j {
appender.stdout = "org.apache.log4j.ConsoleAppender"
appender.'stdout.layout'="org.apache.log4j.PatternLayout"
appender.'stdout.layout.ConversionPattern'='[%r] %c{2} %m%n'
appender.stacktraceLog = "org.apache.log4j.FileAppender"
appender.'stacktraceLog.layout'="org.apache.log4j.PatternLayout"
appender.'stacktraceLog.layout.ConversionPattern'='[%r] %c{2} %m%n'
appender.'stacktraceLog.File'="stacktrace.log"
appender.'stacktraceLog.MaxFileSize'="1MB"
rootLogger="error,stdout"
logger {
grails="error"
StackTrace="error,stacktraceLog"
org {
codehaus.groovy.grails.web.servlet="error" // controllers
codehaus.groovy.grails.web.pages="error" // GSP
codehaus.groovy.grails.web.sitemesh="error" // layouts
codehaus.groovy.grails."web.mapping.filter"="error" // URL mapping
codehaus.groovy.grails."web.mapping"="error" // URL mapping
codehaus.groovy.grails.commons="info" // core / classloading
codehaus.groovy.grails.plugins="error" // plugins
codehaus.groovy.grails.orm.hibernate="error" // hibernate integration
// Hibernate should be on - if you want to catch sql logs
springframework="off"
hibernate="on"
//hibernate.SQL = 'debug'
//hibernate.type = 'trace'
//hibernate.SQL = 'info,hibernate'
//hibernate.type = 'info,hibernate'
//hibernate = 'info,hibernate'
//apache.commons.digester.Digester = 'debug,javaclasses'
}
}
additivity.StackTrace=false
}
try and capture what it is doing, it is also worth running developer tools on your browser whether its firefox of chrome and trying to figure out on what elements it is taking that time - but between the logs and the browser developer tools should lie your answer.
Usually you can fix this by doing
grails clean
on the grails command line (I open it via CRTL+ALT+G in IntelliJ IDEA).
This erases all compiled files and will recompile your project from scratch (afaik), which usually erases errors like that. This is not a real fix for the underlying problem, but it solves the problem. Grails is highly experimental and unstable if you ask me, i have a lot of weird error that usually disappear when doing a clean. Btw i'm using 2.1.5 on Windows 7 x64, too.
Delete stacktrace file in the target folder of your project. It can
get huge. (At present mine is 48 GB).
Check if there is enough space in your C directory.
If you are hot swapping code, then page loads can get slow. So in such cases, restart the dev server (grails app).
Sometimes, requests to the server can hang, where focusing (left or right clicking on the cmd) on the command prompt seems to skip the pause. (weird)
Increasing the JVM permgen, heap spaces depending on your memory might help as well.
Try running the server using command prompt rather within an IDE.
Better use methods for actions than closures.
For a system with 3GB RAM, my environment variable setting is:
JAVA_OPTS
-Xms512m -Xmx1g
The STS.ini settings:
-startup
plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.100.v20110502
-product
com.springsource.sts.ide
--launcher.defaultAction
openFile
--launcher.XXMaxPermSize
384M
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xmn128m
-Xms1024m
-Xmx1024m
-Xss2m
-XX:PermSize=256m
-XX:MaxPermSize=512m
-XX:MaxGCPauseMillis=10
-XX:MaxHeapFreeRatio=50
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing
-XX:+UserParallelGC
8) Maybe the problem is with the JDK and grails versions combination. There seems to be an error with OpenJDK 1.7u25 and spring loaded. Okay, you are not using OpenJDK, but try with other version anyway. Try with JDK1.7u03.
9) Try JVM with -server flag, and see if it improves runtime performance.
grails run-app -server
So the reason why this was happening:
JDK 1.7.25