When exec make-boot-jar.sh I get the following error:
2017-06-17 02:12:42,209 INFO - Successfully loaded base configuration from file at '/home/hadoop/terracotta-3.7.7/tc-config.xml'.
java.lang.ArrayIndexOutOfBoundsException: 9216
at com.tc.asm.ClassReader.readClass(ClassReader.java:2015)
at com.tc.asm.ClassReader.accept(ClassReader.java:469)
at com.tc.asm.ClassReader.accept(ClassReader.java:425)
Has anyone ever been in this situation?
Given the magic Terracotta was weaving inside a JVM and the fact that DSO is discontinued, I am pretty sure the error is because Terracotta 3.7.7 is not compatible with Java 8.
We are using SonarQube 5.1.2 using Ant runner 2.2 and Java pluging 3.12 for the analysis. I can succesfully analyse my project. I just keep getting this error:
Java bytecode has not been made available to the analyzer. The org.sonar.java.bytecode.visitor.DependenciesVisitor#d678716, org.sonar.java.checks.unused.UnusedPrivateMethodCheck#58e28efd, CycleBetweenPackages rule are disabled.
So I need to configure my sonar.java.binaries and sonar.java.test.binaries properties (following http://docs.sonarqube.org/display/PLUG/Java+Plugin+and+Bytecode).
Which I think I have done correctly:
<property name="project.dir" value="${basedir}/xalg.prj/h3_service_fo" />
<property name="sonar.java.binaries" location="${project.build.dir}/classes/main" />
<property name="sonar.java.test.binaries" value="${project.build.dir}/classes/test" />
Which resolve to the following valid directories for the above properties:
basedir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj
project.dir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo
sonar.java.binaries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\xalg.prj\\h3_service_fo\\build\\classes\\main
sonar.java.test.binaries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/build/classes/test
But I keep getting:
Java bytecode has not been made available to the analyzer. The org.sonar.java.bytecode.visitor.DependenciesVisitor#d678716, org.sonar.java.checks.unused.UnusedPrivateMethodCheck#58e28efd, CycleBetweenPackages rule are disabled.
And for the life of me, I can not figure out what values I need to give the sonar.java.binaries and sonar.java.test.binaries properties. I even tried using sonar.binaries, which gave me the following output:
Binary dirs: xalg.prj/h3_service_fo/build/classes
Which I did not get using either sonar.java.binaries or sonar.java.test.binaries. I also got:
JavaClasspath initialization...
sonar.binaries and sonar.libraries are deprecated since version 2.5 of sonar-java-plugin, please use sonar.java.binaries and sonar.java.libraries instead
Which is to be expected for a deprecated property. But using the sonar.java.binaries property I did not get the "Binary dirs" line in my log.
Using sonar.java.binaries:
Language is forced to java
Load rules
Load rules (done) | time=761ms
Code colorizer, supported languages: cs,plsql
Initializers :
Base dir: D:\appl\BuildAgent\work\H3\src.prj\java.prj
Working dir: D:\appl\BuildAgent\work\H3\src.prj\java.prj\.sonar
Source paths: xalg.prj/h3_service_fo/src/main/java
Test paths: xalg.prj/h3_service_fo/src/test/java
Source encoding: windows-1252, default locale: en_US
Index files
Versus using sonar.binaries:
Language is forced to java
Load rules
Load rules (done) | time=736ms
Code colorizer, supported languages: cs,plsql
Initializers :
Base dir: D:\appl\BuildAgent\work\H3\src.prj\java.prj
Working dir: D:\appl\BuildAgent\work\H3\src.prj\java.prj\.sonar
Source paths: xalg.prj/h3_service_fo/src/main/java
Test paths: xalg.prj/h3_service_fo/src/test/java
Binary dirs: xalg.prj/h3_service_fo/build/classes
Source encoding: windows-1252, default locale: en_US
Index files
I also looked into the source code of SonarQube, SonarQube Java Plugin and the SonarQube Scanner for instances of either "Java bytecode has not been made available to the analyzer." or sonar.java.binaries. I found plenty on sonar.java.binaries, but nothing on "Java bytecode has not been made available to the analyzer." So I have no clue what conditions exactly trigger that error.
I also tried the following permutations on sonar.java.binaries:
<property name="sonar.java.binaries" location="${project.build.dir}/classes" />
<property name="sonar.java.binaries" location="${project.build.dir}/classes/main/nl" />
But that did nothing either.
What is weird is that Squid seems to resolve the classpath just fine:
----- Classpath analyzed by Squid:
D:\appl\BuildAgent\work\H3\src.prj\java.prj\xalg.prj\h3_service_fo\build\classes\main
So, what am I missing? What am I doing wrong? Thanks in advance.
Update 2016-09-08:
Removed the entire log, the post become to long.
A subset with the (I think) relevant paths:
project.build.dir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/build
project.dir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo
project.src.dir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/src
sonar.dir=D\:/appl/sonarqube-5.1.2
sonar.working.directory=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\.sonar
sonar.projectBaseDir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj
sonar.jacoco.reportPath=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/build/jacoco/test.exec
sonar.junit.reportsPath=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/build/test-results
sonar.sources=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/src/main/java
sonar.java.binaries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\xalg.prj\\h3_service_fo\\build\\classes\\main
sonar.java.libraries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/_deploy/*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/_repos/lib/*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/_repos/provided/*.jar
sonar.tests=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/src/test/java
sonar.java.test.binaries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/xalg.prj/h3_service_fo/build/classes/test
sonar.java.test.libraries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/_deploy/*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/_repos/lib/*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj/_repos/provided/*.jar
The paths have exactly the same format as in my post. Could it be that the Sonar Ant runner can't figure out a path with both backslashes and slashes?
Update 2016-09-16:
Removed the entire log, the post become to long.
A subset with the (I think) relevant paths:
project.build.dir=xalg.prj\\\\h3_service_fo\\\\build
project.dir=xalg.prj\\\\h3_service_fo
project.src.dir=xalg.prj\\\\h3_service_fo\\\\src
sonar.dir=D\:\\\\appl\\\\sonarqube-5.1.2
sonar.working.directory=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\.sonar
sonar.projectBaseDir=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj
sonar.jacoco.reportPath=xalg.prj\\\\h3_service_fo\\\\build\\\\jacoco/test.exec
sonar.junit.reportsPath=xalg.prj\\\\h3_service_fo\\\\build\\\\test-results
sonar.sources=xalg.prj\\\\h3_service_fo\\\\src\\\\main\\\\java
sonar.java.binaries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\xalg.prj\\h3_service_fo\\build\\classes\\main
sonar.java.libraries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\\\_deploy\\\\*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\\\_repos\\\\lib\\\\*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\\\_repos\\\\provided\\\\*.jar
sonar.tests=xalg.prj\\\\h3_service_fo\\\\src\\\\test\\\\java
sonar.java.test.binaries=xalg.prj\\\\h3_service_fo\\\\build\\\\classes\\\\test
sonar.java.test.libraries=D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\\\_deploy\\\\*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\\\_repos\\\\lib\\\\*.jar,D\:\\appl\\BuildAgent\\work\\H3\\src.prj\\java.prj\\\\_repos\\\\provided\\\\*.jar
Some paths have become relative, but I think that is because TeamCity changed the Ant file to the file in SVN.
The sonar.java.binaries is absolute and it definitely points to the correct directory.
But I still get this error:
09:17:52.299 INFO - Java Main Files AST scan done: 1579 ms
09:17:52.301 INFO - 2/2 source files have been analyzed
09:17:52.305 WARN - Java bytecode has not been made available to the analyzer. The org.sonar.java.bytecode.visitor.DependenciesVisitor#757a48f9, org.sonar.java.checks.unused.UnusedPrivateMethodCheck#1adf492b, CycleBetweenPackages rule are disabled.
The classpath is still interpreted just fine:
[sonar:sonar] 09:17:51.971 DEBUG - ----- Classpath analyzed by Squid:
[sonar:sonar] 09:17:51.972 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\xalg.prj\h3_service_fo\build\classes\main
[sonar:sonar] 09:17:51.973 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\batch.daemon.jar
[sonar:sonar] 09:17:51.974 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\buildinfo.jar
[sonar:sonar] 09:17:51.975 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h2_shared.jar
[sonar:sonar] 09:17:51.975 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_generator.jar
[sonar:sonar] 09:17:51.976 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_loadtest.jar
[sonar:sonar] 09:17:51.977 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_common.jar
[sonar:sonar] 09:17:51.977 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xalg.jar
[sonar:sonar] 09:17:51.978 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xalg_dao.jar
[sonar:sonar] 09:17:51.979 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xalg_mappers.jar
[sonar:sonar] 09:17:51.979 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xalg_procedures.jar
[sonar:sonar] 09:17:51.980 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xcare.jar
[sonar:sonar] 09:17:51.981 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xcare_dao.jar
[sonar:sonar] 09:17:51.982 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xcare_mappers.jar
[sonar:sonar] 09:17:51.982 DEBUG - D:\appl\BuildAgent\work\H3\src.prj\java.prj\_deploy\h3_model_xcare_procedures.jar
Could the Sonar Ant runner have a problem with the escaped back slashes?
This is what I use, and it works.
sonar-scanner -Dsonar.projectKey=projectName
-Dsonar.gitlab.commit_sha=$CI_BUILD_REF
-Dsonar.gitlab.ref_name=$CI_BUILD_REF_NAME -Dsonar.sources=directory\src\
-Dsonar.java.binaries=.build\libs\
You need to point sonar.java.binaries to a directory that contains jars. I would't try to get fancy with wildcards and file extensions, that's not the same thing. You need a directory as an argument, not a regular expression for files.
I don't know everything about sonar scanner, but my configuration works.
Take my example into context, I use it in a gitlab runner pipeline. Your double backslashes should be fine, but you can always substitute them for forwards slashes in your config files.
Here are some options for a Gradle multi-project. I'm running in CI (Jenkins) but the principles apply.
Options:
Hand-maintain a hardcoded sonar.java.binaries entry, eg:
sonar.java.binaries=subproject1/build/classes,subproject2/build/classes, (etc)
Set it to the top-level directory of the project:
sonar.java.binaries=.
Use a script to generate your own props file at runtime, for example:
cat > sonar-project.properties <<EOF
sonar.projectKey=XXXX
sonar.projectVersion=YYYY
sonar.sources=$(find . -path '*/src/main' | xargs | tr ' ' ',')
sonar.java.binaries=$(find . -path '*/build/classes/java' | xargs | tr ' ' ',')
EOF
Note that the above also applies to sonar.sources, and it is likely going to need to be in sync with sonar.java.binaries. Having binaries be a superset of source seems to be OK. Obviously, if your sources value is too broad (ie includes tests, etc), you'll get more noise. The advantage of using a script is that you can customize these heuristics to your taste.
you have to provide the parameter sonar.java.libraries.
if you use maven you can add these inside the pom.xml as a property
<project>
...
<properties>
...
<sonar.java.libraries>target</sonar.java.libraries>
</properties>
</project>
or as run parameter -Dsonar.java.libraries=target
Based on the documentation at https://docs.sonarqube.org/latest/analysis/languages/java/
The purpose of sonar.java.binaries path is:
Comma-separated paths to directories containing the compiled bytecode files corresponding to your source files.
For Gradle, the default path is at build/classes, so I would set:
sonar.java.binaries=build/classes
IDK but adding this sonar.java.binaries= **/*.bin to sonar-project.properties helped me
Our application is a RoR app, and currently uses JRuby version 1.7.22, and JRE 8_65. Our app is an on-prem solution, so we use JRuby to host our application on JVM at the target, Windows Server 2012 R2 system. We compile our ruby code, using
jruby -S jrubyc
This takes the .rb file and compiles it to a .class file. In the original .rb, it loads in the class file, like so.
load __FILE__.sub(/\.rb$/, ".class")
This all works with JRuby 1.7.22
Now, we want to update JRuby to 9.0.5.0, but are experiencing some problems when it comes to deploying our application. Basically, that line of code above inside of the .rb file is not working anymore, and we get the error when trying to run a rake db:setup
rake aborted!
LoadError: C:/appname/app/models/app_attribute.class is not compiled Ruby; use java_import to load normal classes
C:/appname/app/models/app_attribute.rb:1:in `<top>'
C:/appname/db/seeds.rb:10:in `<top>'
C:/appname/db/seeds.rb:9:in `block in (root)'
Tasks: TOP => db:setup => db:seed
(See full trace by running task with --trace)
Great. So I replace load with java_import
rake aborted!
ArgumentError: not a valid Java identifier: C:/appname/app/models/app_attribute.class
uri:classloader:/jruby/java/core_ext/object.rb:43:in `block in java_import'
uri:classloader:/jruby/java/core_ext/object.rb:34:in `java_import'
C:/appname/app/models/app_attribute.rb:1:in `<top>'
C:/appname/db/seeds.rb:10:in `<top>'
C:/appname/db/seeds.rb:9:in `block in (root)'
Tasks: TOP => db:setup => db:seed
(See full trace by running task with --trace)
Still not working, no matter what I try. I looked at this post: https://github.com/jruby/jruby/issues/3018
I tried to pass the parameter
jruby -Xaot.loadClasses=true
But I get a warning saying that aot.LoadClasses is not recognized. EVEN THOUGH I see it in the properties when I type
jruby -Xproperties
I have done A LOT of research on this, and have probably have looked at everything on the internet regarding this. Any input will be greatly appreciated. Is there something I missing? I am not fully adept in Java.
Thank you.
might be the same issue as https://github.com/jruby/jruby/issues/3651
which means you'll need to wait for 9.1 or use a snapshot http://ci.jruby.org/
since, the error is slightly different you should look into reproducing with snapshot and if it fails (might be Windows related) a step-by-step reproduction might speed-up getting the issue resolved.
jruby -Xaot.loadClasses=true
this is not needed with Warbler
But I get a warning saying that aot.LoadClasses is not recognized. EVEN THOUGH I see it in the properties when I type
hmm, could you reproduce this with an empty script and no JRUBY_OPTS ?
I have done A LOT of research on this, and have probably have looked at everything on the internet regarding this. Any input will be greatly appreciated.
you might want to try looking into the issue next time :) or considering getting some support
Is there something I missing? I am not fully adept in Java.
you shouldn't be missing anything - its not a Java issue ...
A BulkBeanException is being thrown when iBatis is attempting to apply a result map, but is not consistent across deployments via the same jar (local is fine, server deployment is not).
I figured out how to stop the problem (see my answer below), but am more interested in hearing about strategies to diagnose why the cglibification happened/happened differently in different runtime environments. I assume the inconsistent behavior is due to differences in the order in which libraries are loaded, but have not figured out how to confirm this ($PATH and $CLASSPATH resolved to the same thing in different environments). Is there something else I should be looking at?
Got error
java -jar <jar> on CentOS box
Mule runtime via Eclipse on OS X
Did not get error
java -jar <jar> on OS X
JUnit via Maven on OS X
JUnit via Eclipse on OS X
stack trace
Caused by: com.ibatis.common.jdbc.exception.NestedSQLException:
--- The error occurred in ibatis/MyClassName.xml.
--- The error occurred while applying a result map.
--- Check the MyClassName.result.
--- The error happened while setting a property on the result object.
--- Cause: net.sf.cglib.beans.BulkBeanException: 1
at com.ibatis.sqlmap.engine.mapping.statement.MappedStatement.executeQueryWithCallback(MappedStatement.java:204) ~[mybatis-2.3.5.jar!/:?]
at com.ibatis.sqlmap.engine.mapping.statement.MappedStatement.executeQueryForList(MappedStatement.java:139) ~[mybatis-2.3.5.jar!/:?]
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForList(SqlMapExecutorDelegate.java:578) ~[mybatis-2.3.5.jar!/:?]
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForList(SqlMapExecutorDelegate.java:552) ~[mybatis-2.3.5.jar!/:?]
at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForList(SqlMapSessionImpl.java:118) ~[mybatis-2.3.5.jar!/:?]
at org.springframework.orm.ibatis.SqlMapClientTemplate$3.doInSqlMapClient(SqlMapClientTemplate.java:298) ~[mybatis-2-spring-1.0.1.jar!/:1.0.1]
at org.springframework.orm.ibatis.SqlMapClientTemplate$3.doInSqlMapClient(SqlMapClientTemplate.java:296) ~[mybatis-2-spring-1.0.1.jar!/:1.0.1]
at org.springframework.orm.ibatis.SqlMapClientTemplate.execute(SqlMapClientTemplate.java:203) ~[mybatis-2-spring-1.0.1.jar!/:1.0.1]
... 77 more
The Java bean onto which iBATIS was attempting to apply the result map had unusual (non-bean-conformant?) setters. These setters did not return void as is standard, but returned the object itself so that set operations could be chained (we have some Haskell programmers working on this project :)).
Where it was occurring it was solved by changing the setter methods back to their previous state where they were defined with void return.
Had the same issue , ibatis was trying to set null value to primitive double which was causing the issue
Trying to run my GWT app, I get
EntryPoint initialization exception
Exception while loading module ch.swisstph.mortqual.mqui.client.MqInput. See Development Mode for details.
com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
at com.google.gwt.dev.shell.ModuleSpace.rebindAndCreate(ModuleSpace.java:513)
at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:385)
at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200)
at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:526)
at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
at java.lang.Thread.run(Thread.java:722)
in the web browser, and just
/usr/lib/jvm/java-6-openjdk/bin/java -Xmx256m -Didea.launcher.port=7537 -Didea.launcher.bin.path=/home/dhardy/code/download/idea-IU-129.239/bin -Dfile.encoding=UTF-8 -classpath /home/install/gwt/gwt-dev.jar:/home/dhardy/p/mortqual/mqui/src:/usr/lib/jvm/java-6-openjdk/jre/lib/compilefontconfig.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/jsse.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/jce.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/management-agent.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/rt.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/javazic.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/resources.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/charsets.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/ext/java-atk-wrapper.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/ext/sunpkcs11.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/ext/sunjce_provider.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/ext/pulse-java.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/ext/localedata.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/ext/zipfs.jar:/usr/lib/jvm/java-6-openjdk/jre/lib/ext/dnsns.jar:/home/dhardy/p/mortqual/mqui/out/test/mqui:/home/dhardy/p/mortqual/mqui/out/production/mqui:/home/install/appengine-java-sdk/lib/shared/jsp-api.jar:/home/install/appengine-java-sdk/lib/shared/appengine-local-runtime-shared.jar:/home/install/appengine-java-sdk/lib/shared/el-api.jar:/home/install/appengine-java-sdk/lib/shared/servlet-api.jar:/home/install/appengine-java-sdk/lib/user/appengine-api-1.0-sdk-1.7.5.jar:/home/install/gwt/gwt-user.jar:/home/dhardy/p/mortqual/anacod/target/test-classes:/home/dhardy/p/mortqual/anacod/target/classes:/home/dhardy/.m2/repository/net/sourceforge/jexcelapi/jxl/2.6.12/jxl-2.6.12.jar:/home/dhardy/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar:/home/dhardy/.m2/repository/com/beust/jcommander/1.30/jcommander-1.30.jar:/home/dhardy/.m2/repository/org/apache/poi/poi/3.9-20130311/poi-3.9-20130311.jar:/home/dhardy/.m2/repository/org/apache/poi/poi-ooxml/3.9/poi-ooxml-3.9.jar:/home/dhardy/.m2/repository/org/apache/poi/poi-ooxml-schemas/3.9/poi-ooxml-schemas-3.9.jar:/home/dhardy/.m2/repository/org/apache/xmlbeans/xmlbeans/2.3.0/xmlbeans-2.3.0.jar:/home/dhardy/.m2/repository/stax/stax-api/1.0.1/stax-api-1.0.1.jar:/home/dhardy/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar:/home/dhardy/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar:/home/install/gwt/validation-api-1.0.0.GA-sources.jar:/home/install/gwt/validation-api-1.0.0.GA.jar:/home/dhardy/code/download/idea-IU-129.239/lib/idea_rt.jar com.intellij.rt.execution.application.AppMain com.google.gwt.dev.DevMode -war /home/dhardy/.IntelliJIdea12/system/gwt/mqui.5589a251/mqui.33ff3210/run/www -remoteUI 7901:IntelliJIdea -startupUrl mqInput.html ch.swisstph.mortqual.mqui.mqui
log4j:WARN No appenders could be found for logger (org.apache.jasper.compiler.JspRuntimeContext).
log4j:WARN Please initialize the log4j system properly.
Dev Mode initialized. Startup URL:
http://127.0.0.1:8888/mqInput.html?gwt.codesvr=127.0.0.1:9997
on the command line. There are no logs I can find (I tried configuring log4j via a .properties file, which removed its warnings but still didn't give me any logs).
So how do I solve this?
The two most likely causes are renaming of my start-up page and pushing some code out to a library.
try putting -logLevel SPAM in your command line arguments, this will print detailed logs, also you can put explicit GWT.log("message") in your entry point code, that will tell your how far it is going (normal logging doesn't work directly with gwt).
This page describes how to debug GWT in general, how ever my suggestion would be run debug this directly in eclipse with gwt plugin, GWT support in eclipse is amazing.