I'm using jacocoagent.jar having placed in my app code. But when I restarts the app service not getting the jacoco.exec. Not getting the file even after executing test case using the box where app code is deployed. (provided path of the file in one .conf file).Serv is Geronim used for
Whether jacoco.exec should get created for the first time? once the app service is restarted or once any test case is executed?
By default, JaCoCo generates the .exec file after the server is shut down. If you want to change that behavior, you need to listen to the port where JaCoCo is generating the output and pipe it to another file. This change can be done in the configuration and by running a listener to collect the data generated by JaCoCo.
Related
I have a REST service with a simple get and post method in Java EE. The post method saves the recieved json in a file using Gson and FileWriter. On my local system the file is saved in C:\Users...\Documents\Glassfish Domains\Domain\config. The Get method reads this file and gives out the json.
When I test this on my local system using Postman, everything works fine, but when I deploy the project on a Ubuntu Server vm with Glassfish installed, I am able to connect but I get a http 500 Internal Server Error Code. I managed to find out, that the errors are thrown, when the FileReader/FileWriter tries to do stuff. I suppose that it is restricted to access this directory on a real glassfish instance.
So my question is, if there is a file path where I am allowed to write a file and read it afterwards. This file has to stay there (at least during the applicationr runs) and has to be the same for every request (A scheduler writes some stuff into the file every 24 hours). If anyone has a simple alternative how to save the json in Java EE without an extra database instance, that would be helpful, too :)
If you have access to the server then you can create a directory using the glassfish server user. Configure this path in some property file in your application and then use this property for reading and writing the file. This way you can configure different directory paths in different environments.
I'm running apache with django and mod_wsgi enabled in 2 different processes.
I read that the second process is a on-change listener for reloading code on change, but for some reason the ready() function of my AppConfig class is being executed twice. This function should only run once.
I understood that running django runserver with the --noreload flag will resolve the problem on development mode, but I cannot find a solution for this in production mode on my apache webserver.
I have two questions:
How can I run with only one process in production or at least make only one process run the ready() function ?
Is there a way to make the ready() function run not in a lazy mode? By this, I mean execute only on on server startup, not on first request.
For further explanation, I am experiencing a scenario as follows:
The ready() function creates a folder listener such as pyinotify. That listener will listen on a folder on my server and enqueue a task on any changes.
I am seeing this listener executed twice on any changes to a single file in the monitored directory. This leads me to believe that both processes are running my listener.
No, the second process is not an onchange listener - I don't know where you read that. That happens with the dev server, not with mod_wsgi.
You should not try to prevent Apache from serving multiple processes. If you do, the speed of your site will be massively reduced: it will only be able to serve a single request at a time, with others queued until the first finishes. That's no good for anything other than a toy site.
Instead, you should fix your AppConfig. Rather than blindly spawning a listener, you should check to see if it has already been created before starting a new one.
You shouldn't prevent spawning multiple processes, because it's good thing, especially on production environment. You should consider using some external tool, separated from django or add check if folder listening is already running (for example monitor persistence of PID file and it's content).
For the development of my own sonar plugin i want to be able to debug.
after quite a while I found out how to run the sonarqube server in debug mode. Therefore I followed the instruction of the following website. enter link description here
When I started the server in debug modus an connect eclipse by using the debug configuration, the server starts but it do not not stop at the breakpoints that I have been set. I have set breakpoints to extension point (classes) like the one which extends the SonarPlugin class or the one which extends the RuleRepository class. The logs of these classes are part of the server log file, so I'm pretty sure that this classes are executed. Nevertheless it doesn't stop at the breakpoints.
Anyone ideas whats the problem?
The server runs as three process - a parent application, the web server and a search server. Plugins are loaded into the web server so you need to start this with debug arguments. The options for this seem to have changed and are not yet reflected in the documentation. To debug the web server put:
sonar.web.javaAdditionalOpts=-agentlib:jdwp=transport=dt_socket,suspend=y,server=y,address=9001
into your sonar.peroperties file and start sonar using the StartSonar script. This will launch all three applications, but with the web server suspended. Attach your debugger to port 9001 and you should find your plugin main class and rules definition breakpoints are hit.
I m trying to integrate Jacoco with Websphere to get the code coverage by Manual Testing.
I have set JVM arguments as below
![-javaagent:C:\Shankara\Software\jacoco-0.7.2.201409121644\lib\jacocoagent.jar=destfile=C:\Shankara\Software\jacoco.exec,append=true,includes=com.*][1]
i m able to get exec file successfully however the coverage is still red colour. Please assists me on this urgently
Did you stop the target JVM instance.
Until you do that, you won't get the code coverage data (of source main code) via running your non-unit tests.
Try this:
1. Attach jacocoagent.jar and pass params (like you have done) then
2. Run your tests (manual / automated which will exercise / cover the main source code), then
3. Stop the target JVM instance/session (which is WebSphere), then
4. You'll notice jacoco file size will be a little more than what you're getting before.
Use this jacoco exec (which you get after stopping the target JVM instance) for running jacocoTestReport to get the final code coverage %.
Note: If you don't want to stop the target JVM session/instance where your application/webservice is running then read Jacoco documentation as there's a way to do that too.
See here: http://www.eclemma.org/jacoco/trunk/doc/agent.html
Specially the parameters:
dumponexit If set to true coverage data will be written on VM shutdown. The dump can only be written if either file is specified or the output is tcpserver/tcpclient and a connection is open at the time when the VM terminates. true
output Output method to use for writing coverage data. Valid options are:
file: At VM termination execution data is written to the file specified in the destfile attribute.
tcpserver: The agent listens for incoming connections on the TCP port specified by the address and port attribute. Execution data is written to this TCP connection.
tcpclient: At startup the agent connects to the TCP port specified by the address and port attribute. Execution data is written to this TCP connection.
none: Do not produce any output.
Please see the security considerations below.
address IP address or hostname to bind to when the output method is tcpserver or connect to when the output method is tcpclient. In tcpserver mode the value "*" causes the agent to accept connections on any local address. loopback interface
port Port to bind to when the output method is tcpserver or connect to when the output method is tcpclient. In tcpserver mode the port must be available, which means that if multiple JaCoCo agents should run on the same machine, different ports have to be specified.
I have a project that is being built using CruiseControl.NET. The project contains an 'MSBuild task' that runs the build for the project and also the unit tests. The unit test in turn is just a MSBuild 'exec' task that runs an executable.
The unit test involves some .NET remoting. And when the unit tests are run through the system command prompt, the software's window opens up, tests run and the process exits.
When I force a build through the web dashboard, the build hangs at the point where the unit test starts running. The software's window does not open up, but the executable is running. If the process is killed through the task explorer, the build goes through with a 'Failure' status. This happens when I run ccnet as a windows service.
If I run CCNet directly (not as a windows service) and force a build through the web dashboard, the build and unit tests go through fine as expected. (with the window of the software opening up.)
It looks like there is a deadlock in the case where CCNet is run as a windows service. I am guessing it is related to the standard output/error streams.
Is this is known problem?
What might be the problem going on?
Any suggestions on debugging this?
How can I get around it?
(I am using CCNet version 1.4.4 SP1)
When CCNet is running as a service it is not going to have access to the display, so don't expect to see anything on the screen in this configuration. The first thing I would check is the permissions - make sure the service runs as an account that has permissions to access whatever resources you need. You also have CCNet log files, which you can find via Dashboard.
On a side note, try TeamCity instead of CCNet, its 10 years ahead.
Maybe this answer will help :
delphi windows service can't download file from internet
You should know that when running CCNet as an application (the dosbox) it uses the environment variables and all rights from the logged account. So it may connect to a server, use cached passwords, get registry variables for this account.
BUT when ran as a service, the account is the one you provided : LocalSystem for exampe, where env. varibales are not the same.
So, what you can do is to change the CCNet service account for test. Change it to your user account (with password), and I'm sure it will work better !