I am trying to Obtain Cobertura Code Coverage reports for a Jboss AS 7 Application.
I have properly Instrumented the app java artefacts and they all deploy fine.
But I am not able to get Cobertura to dump the Cobertura.ser report upon stopping the AS.
As mentioned in the Cobertura FAQ I have started the AS with -Djboss.shutdown.forceHalt=false but this has no effect. Any Clues what could be done ... I have different test suites that I want to generate coverage reports so stopping the AS is my best option to dump the Cobertura.ser from it.
Assuming that you have troubles updating the run.bat file in your jboss-setup/bin folder,
can you replace the line
set JAVA_OPTS=%JAVA_OPTS% -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
of run.bat file with the below line
set JAVA_OPTS=%JAVA_OPTS% -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.shutdown.forceHalt=false -Dnet.sourceforge.cobertura.datafile="%JBOSS_HOME%\bin\cobertura.ser"
I have assumed that 'cobertura.ser' is placed in your jboss-setup/bin folder.
Related
I am trying to debug a java application using property - System.setProperty("javax.net.debug", "ssl"); in my main class.
I see debug logs in console when I run application using Eclipse during development. However, when I try to run same application using webstart I am not able to see any debug logs in any directory so far.
Is there a specific location where this logs are stored during execution?
I also tried passing debug option to run the jar from command line as java -Djavax.net.debug=ssl -jar xyz.jar but still cannot find logs generated.
Can anyone please help me understand to obtain SSL debug logs for java application?
Thank you.
They aren't stored anywhere. They are printed to System.out or System.err.
In some cases, from command line you can write debug output directly into a file:
java -Djavax.net.debug=all -jar xyz.jar > out.log
I'm working my way through a book about "Java EE 7 for Glassfish", with the server installed on Fedora Linux.
I have a simple stateless session bean SimpleSessionBean deployed on the server and I am trying to approach that SimpleSessionBean via SessionBeanClient and the Glassfish command line tool appclient, running a client jar. Everything from the book, so it should work. The client however can't find SimpleSessionBean. Apparently a class path issue. In the server logs nothing happened.
I can't find any pointers how Glassfish should be properly installed. Everything works within the server. I can approach installed war files from facelets running in a browser.
It is probably a matter of setting $PATH right or something or some other environment variable. Any pointers to relevant literature?
Thanks in advance for any suggestions!
UPDATE1: error message
From the bash terminal window where I run appclient:
[fedora#localhost bin]$ ./appclient -client /home/fedora/Downloads/6886EN_04_Code/ch04_src/simplesessionbeanclient/target/simplesessionbeanclient.jar
Jul 06, 2017 12:52:57 PM org.glassfish.apf.impl.DefaultErrorHandler error
SEVERE: Class [ Lnet/ensode/glassfishbook/SimpleSession; ] not found.
Error while loading [ class net.ensode.glassfishbook.SessionBeanClient ]
Exception in thread "main" java.lang.NoClassDefFoundError: net/ensode/glassfishbook/SimpleSession
at net.ensode.glassfishbook.SessionBeanClient.invokeSessionBeanMethods(SessionBeanClient.java:12)
at net.ensode.glassfishbook.SessionBeanClient.main(SessionBeanClient.java:19)
Caused by: java.lang.ClassNotFoundException: net.ensode.glassfishbook.SimpleSession
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at org.glassfish.appclient.client.acc.ACCClassLoader.findClass(ACCClassLoader.java:237)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
UPDATE2: From the Glassfish book:
We are using Maven to build our code. For this example, we used
the Maven Assembly plugin (http://maven.apache.org/plugins/maven-assembly-plugin/) to build a client JAR file
that includes all dependencies; this frees us from having to specify
all the dependent JAR files in the -classpath command-line option
of the appclient utility. To build this JAR file, simply invoke mvn
assembly:assembly from the command line.
SOLUTION: the missing link was producing a client jar with additional jar's "on board" so to speak. Proceed as follows (at least in Eclipse): select pom.xml > right-click > Run As > Maven build... > enter in Goals field: assembly:assembly> Apply/Run.
The result will be that you will find TWO jars under your target folder: xxxclient.jar and xxxclient-jar-with-dependencies.jar.
From the command line in bash execute from the folder with latter jar:
/path_to/appclient -client xxxclient-jar-with-dependencies.jar
After a very long wait (on my $200 mini Linux box) the HelloWorld-ish server EJB gets finally properly called.
Your assumption is right.
You are missing net.ensode.glassfishbook.SimpleSession in your classpath.
From an older book online:
...executed through the appclient utility. This utility can be found at
[glassfish installation directory]/glassfish/bin/. Assuming this path
is in the PATH environment variable, and assuming we placed our client
code in a JAR file called simplesessionbeanclient.jar, we would
execute the above client code by typing the following command in the
command line:
appclient -client simplesessionbeanclient.jar
It seems that you've started from
.../bin/./appclient -client
/home/fedora/Downloads/6886EN_04_Code/ch04_src/simplesessionbeanclient/target/simplesessionbeanclient.jar
You need SimpleSession.class in your CLASSPATH (or in a jar in that classpath).
Usually java checks the current directory first (which is your bin folder). If the class is not found (its not, since its in your simplesessionbeanclient folder), it searches for that class in the classpath (where you did not add the simplesessionbeanclient folder).
Try
appclient -client simplesessionbeanclient.jar
from the folder where simplesessionbeanclient.jar is located.
If you don't want to add the appclient folder to your path start with
/your/path/to/appclient -client simplesessionbeanclient.jar
(again from the folder where simplesessionbeanclient.jar is located)
Update:
If you still get a ClassNotFoundException have a look if it is missing in your jar file (jars are Zip-File, you could use your Zip-Tools):
jar tf simplesessionbeanclient.jar
if there is a SimpleSession.class
I did the following to fix my problem:
Use appclient -classpath (instead of appclient -client)
Use the regular project JARs (instead of the one generated by mvn assembly:assembly)
Deploy the EJB to Glassfish (simplesessionbean.jar)
The example code from a more recent book "Java EE 8 Application Development" by David R. Heffelfinger (the same author of "Java EE 7 for Glassfish") is almost exactly the same (the only minor difference is classes are packaged in "net.ensode.javaee8book" instead of "net.ensode.glassfishbook").
When running appclient.bat -client simplesessionbeanclient-jar-with-dependencies.jar I kept getting:
java.lang.ClassNotFoundException: <mainclass>
errors. This was because the POM was assembling a manifest with <mainClass> value of "net.ensode.glassfishbook.SessionBeanClient" (instead of "net.ensode.javaee8book.SessionBeanClient"). So I decided to avoid using the -client option for appclient.bat and switched to -classpath which allowed me to specify the main class on the command line (which is easier than updating the POM or refactoring the packages to suit the manifest).
But then when running the appclient command:
PS C:\home\programs\java_ee_sdk-8u1\glassfish5\glassfish\bin> .\appclient.bat -classpath "C:\home\code\Java-EE-8-Application-Development-Code-Samples-master\ch04_src\simplesessionbean\target\simplesessionbean.jar;C:\home\code\Java-EE-8-Application-Development-Code-Samples-master\ch04_src\simplesessionbeanclient\target\simplesessionbeanclient.jar" net.ensode.javaee8book.SessionBeanClient
I kept getting:
Root exception is javax.naming.NameNotFoundException: net.ensode.javaee8book.SimpleSession#net.ensode.javaee8book.SimpleSession not found]]
errors. This was solved by deploying the EJB (simplesessionbean.jar) to Glassfish via the Admin Console (this missing step was not mentioned in the book). Running the appclient.bat command then worked.
Screenshot of appclient.bat (takes about 15 seconds to load):
Screenshot of EJB deployment:
Alternatively
You can manually compile the client to include all the dependencies by copying SimpleSession.java and SimpleSessionBean.java from the "simplesessionbean" project to the "simplesessionbeanclient" project (remember to refactor the package statements). This will generate simplesessionbeanclient.jar with the EJBs included (Nb: you still have to deploy the EJBs to the GlassFish server). Also make sure that the <mainClass> element in the POM points to the correct package.
You can now use the -client option:
I tried to follow the war generation instructions by changing the warName in build.gradle to moqui-plus-runtime.war and running gradle addRuntime and then gradle deployTomcat. There were no errors in the war build and I checked to see that the war file got installed as ROOT. I did not make any other changes (still using MoquiDevConf and I already had other system parameters in MoquiInit.properties.)
When I startup tomcat8, I don't see any errors in the log file and it says that it is loading moqui-plus-runtime, but when I make any request in the browser, the localhost_access... log shows 404 for any request.
Can you tell me what things I might of missed or how I would go about debugging this - there is very little info in the log files other than the 404 messages.
I followed the following steps to deploy to a Tomcat instance on the same machine. This is from memory as my production machine is currently offline for the next couple of weeks.
Edit tomcatHome to point to correct location
I personally run a gradle cleanAll first to remove old WARs etc
Run gradle build
Optionally run gradle loadProduction to load the production database, alternatively you can run java -Dmoqui.conf=conf/MoquiProductionConf.xml -jar moqui-1.5.3.war -load -types=seed,seed-initial so that you can pick which data types you want to load into production etc.
Stop Tomcat from running, probably optional but the next step deletes files & folders from a deployed tomcat instance.
Run gradle addRuntimeTomcat this task adds your runtime and also copies over the completed WAR into the Tomcat webapps directory if you set the location correctly in step 1.
Start Tomcat
Check Tomcat logs for any startup errors
Hope this helps
I'm successfully generating 2 .exec files by Jacoco within "build/jacoco" folder after running a Gradle based build and integration tests.
Gradle command:
"gradle clean build integrationTest"
Once done, it generates the following .exec files under build/jacoco folder.
test.exec
integrationTest.exec
Following is my sonar-project.properties file. When, I run "sonar-runner" from Linux prompt it completes but on SonarQube dashboard for this project, I see Unit test says some 34.5% but integration tests says 0.0%. Both .exec files have valid size. I also did "cat" on the .exec files and piped the output to "strings" command in Linux and saw that integrationTest.exec did hit the Tests functions - I have only 1 .java file.
When I run "gradle clean build integrationTest sonarRunner -Dxxx.xxx=yyy -Dyyy.xx=zzz" i.e. by passing all the sonar variable as mentioned in the sonar-project.properties file using -D option, it works but same result on SonarQube project's dashboard. Project's sonar dashboard has both widgets configured for Unit / Integration Tests and I'm including IT tests for showing Overall coverage. Overall coverage is showing 34.5% (which is Unit test % value). Sonar does see test.exec, integrationTest.exec and also auto generates overall-xxx.exec file as well during this operation.
NOTE: I'm no where - while starting tomcat on a separate putty / linux console -OR within Gradle build script, providing any value or setting JAVA Agent for Jacoco. I'm getting integrationTest.exec file and test.exec file already so not sure if JVM needs to be stopped once IT tests are complete running. I don't think I need those as i have valid file size for .exec files.
My ?:
- Why sonar is not getting IT coverage on the dashboard even though I'm setting / passing the following variable correctly:
sonar.jacoco.itReportPath=build/jacoco/integrationTest.exec
-bash-3.2$ cat sonar-project.properties
# Root project information
sonar.projectKey=com:company:product:ProjectA
sonar.projectName=ProjectA
sonar.projectVersion=1.0
# optional description
sonar.projectDescription=ProjectA Service
#Tells SonarQube that the code coverage tool by unit tests is JaCoCo
sonar.java.coveragePlugin=jacoco
#Tells SonarQube to reuse existing reports for unit tests execution and coverage reports
sonar.dynamicAnalysis=reuseReports
# Some properties that will be inherited by the modules
sonar.sources=src/java,test/java,src/java-test
# Sonar Unit Test Report path
sonar.jacoco.reportPath=build/jacoco/test.exec
# Sonar Integration Test Report Path
sonar.jacoco.itReportPath=build/jacoco/integrationTest.exec
sonar.junit.reportsPath=build/UT/results
# Sonar Binaries
sonar.binaries=build/classes/main
Narrowing down the cause: I think it's due to the .exec file for Integration test. To proove it: I passed UT exex file to both reportsPaths in Sonar variables i.e. the following and SonarQube picked both UT/IT test coverage. This prooves that if .exec file for IT tests is good (which I think it's But I need to double check) then Sonar will pick the .exec file and show a valid coverage % instead of 0.0%. Note: the following is just to proove if Sonar is picking the values or not. itReportPath variable should use the .exe file which is generated by Integration tests by Jacoco.
sonar.jacoco.reportPath=build/jacoco/test.exec
# Sonar Integration Test Report Path
#sonar.jacoco.itReportPath=build/jacoco/testintegrationTest.exec
sonar.jacoco.itReportPath=build/jacoco/test.exec
OK Found the issue. I was running integrationTest task in Gradle and was NOT attaching the jacocoagent.jar (as per Jacoco documentation) to the target JVM (Tomcat's instance) scope. Once I did that, I removed jacoco { ... } section from integrationTest task in Gradle (build.gradle or GRADLE_HOME/init.d/some.common.gradle file as this attach jacoco agent to the Java JVM in which Gradle is running). Now, once jacocoagent.jar was attached to Tomcat's JVM (as per the line below which I added in Tomcat's startup.sh script and added the variable to the command which starts Tomcat), then I ran Gradle (integrationTest) task for running IT tests.
PROJ_EXTRA_JVM_OPTS=-javaagent:tomcat/jacocoagent.jar=destfile=build/jacoco/IT/jacocoIT.exec,append=false
Then while Gradle was in progress, tests ran and I got a file (jacocoIT.exec at the given location) with some file size BUT this is not yet the final one. I had to stop the Tomcat session/JVM instance by running Tomcat's stop.sh script. Once Tomcat was stopped, I saw jacocoIT.exec file size increased significantly and this was the valid final jacocoIT.exec file (which I needed for sonarRunner Gradle task OR sonar-runner exectuable to pick and successfully push IT code coverage data to project's sonar dashboard). Once done, I got both UT + IT and it's combined code coverage.
sonar.jacoco.reportPath=build/jacoco/UT/jacocoUT.exec
sonar.jacoco.itReportPath=build/jacoco/IT/jacocoIT.exec
I am fairly new to Griffon and have some experience with Grails.
I have a problem loading a file from the resources directory.
I am using Griffon version 1.4.0.
When I run griffon run-app the following code (inside a Service) to get the location of an XML file works fine:
URL resource = getResourceAsURL('schema.xsd')
assert resource != null : "schema cannot be located"
When I run griffon test-app however the same code produces an assertion error because the returned URL is null. Same behaviour with getResourceAsStream().
This happens in the unit test of said service.
I put the file in ./griffon-app/resources.
What am I doing wrong? Do I have to copy all resources from production to some test resources folder, do I have to edit the build-configuration?
Thanks in advance!
Edit as suggested below I filed a bug report in the griffon-projects issue tracker.
araxn1d is correct, running the tests in integration mode will give you the right answer because the full application gets bootstrapped before tests are run. Now, running this kind of test (a unit test that depends on resources being available in the classpath) encounters a problem because the classpath is not setup correctly. Executing the following command
griffon -Dgriffon.cli.verbose=true test-app --unit --compileTrace=true
will output all classpaths. There you can see that the resources directory points to $USER_HOME/.griffon/1.4.0/projects/<project_name>/resources. If you inspect that directory you'll find the file you're looking for inside griffon-app/resources. This means the test classpath is not accurately configured as it should be $USER_HOME/.griffon/1.4.0/projects/<project_name>/resources/griffon-app/resources instead. This is clearly a bug, most likely found in the $GRIFFON_HOME/scripts/_GriffonClasspath.groovy script. Could you please file a JIRA http://jira.codehaus.org/browse/griffon ticket for it? Thanks!
You should run test-app to run your unit tests. In this case you should mock any refers to real files, otherwise you should implement Integration Tests. Pls see Griffon Testing. Integration tests differ from unit tests in that you have full access to the Griffon application within the test.