I have been trying to generate code coverage for my web application using Cobertura and Junit but am running into problems. My webapp is a Java web application deployed on WebSphere Liberty Profile. I have followed the steps mentioned here: https://github.com/cobertura/cobertura/wiki/FAQ#using-cobertura-with-a-web-application
My steps are as follows:
Instrument classes using cobertura-instrument ant task.
Put cobertura.jar in the lib folder of my webapp (so that it is on the classpath)
Start Liberty
Run Junits (JUnit runs in a separate JVM other than the Liberty JVM)
The problem is that, cobertura.ser file is not generated when I stop liberty. I have tried the "hack" mentioned here:
https://github.com/cobertura/cobertura/wiki/FAQ#using-cobertura-with-a-web-application
It seemed to work (I actually got some coverage info), but I was seeing that the cobertura.ser file was repeatedly being initialized to zero size and then the size increased to some number, so I am a little hesitant to use this. Moreover, this requires change in the code itself, and depends on the logout code being called, which is not quite ideal for automation.
But I am more interested in a setting for Websphere Liberty such as the one described for JBoss
-Djboss.shutdown.forceHalt=false
In particular, a jvm setting that would allow Cobertura to detect the JVM shutdown hook called by Liberty profile. Is there such a setting for WebSphere/Liberty?
The liberty profile doesn't ever call Runtime.halt so all shutdown hooks should be called appropriately. I thought I'd take a look to reproduce and I think I managed to get it working (I say I think because none of the command line scripts worked so I may still have done something wrong)
Wrote a simple servlet war
Downloaded cobertura and put the cobertura-2.1.1.jar and all the jars in the downloads lib folder into the WEB-INF/lib of my war
Ran the java InstrumentMain class to instrument the classes in WEB-INF/classes (choosing to overwrite them)
Started the server
Accessed the application
Shutdown the server
at the end I looked in the WEB-INF/classes and there was a cobertura.ser file that was 1480 bytes (i.e. non-zero.). When I ran the report tool on this it said I had no coverage, so I deleted the file and went back to reproduce. The cobertura.ser file in WEB-INF/classes wasn't generated. Instead I looked in the server working directory (in case it was there instead) and it wasn't. When I generated the report on this I got coverage.
So some possible things to look for:
Is this the corbertura.ser you are looking for? Look in the usr/servers/ folder to see if there is one there.
Did the instrumented classes end up in the app prior to or instead of the non-instrumented ones
Was the cobertura dependencies available.
Related
Is it possible to convert the standalone.xml (or other configured Wildfly/JBoss profile XML file) to a series of commands or script that can be run by jboss-cli.sh? I have a Wildfly 11 instance that I've made config changes to. I'd like to be able to "templatize" it and have the configuration duplicated using shell scripts during my server deployment. Is there a way to export that config as jboss-cli.sh commands?
I haven't tried it on wildfly 11, but previously on wildfly 9 and 10 i've used https://github.com/tfonteyn/profilecloner to generate jboss-cli scripts for profile creation from scratch. The result still required manual intervention, because cli script sometimes broke order of added elements.
Also, due to bugs in Wildfly 10, adding some subsystems from scratch in jboss-cli was not possible - root element refused to be added without subelement, and vise versa (unfortunately i've lost a ticket number where issue was tracked).
Since in my environment we are using domain mode, we started to copy pre-configured profile with /profile=template-name:clone(to-profile=new-profile), but that's irrelevant in standalone case.
I've been trying to follow the
Setting Up Stackdriver Debugger for Java applications on Google Compute Engine, but am running into issues with Stackdriver Debug.
I'm building my .war file from a separate build server, then deploying it to my GCE server. I added the agent to the start command via /etc/defaults, and my app appears in the https://console.cloud.google.com/debug control panel. The version I set in the run command matches the revision that shows up in the source-context(s).json files.
However when I click open the app, I see the message that
No source version information was provided by the deployed application
I connected the app's git repo as a mirrored cloud repository, and can browse the source files in the sidebar of the Stackdriver Debug page. But, If I browse to a file and add a breakpoint I get an error that the error "File was not found in the executable."
I have ran the gcloud preview app gen-repo-info-file command, which created two basic json files storing my git repo and revision. Is it supposed to do anything else?
I have tried running jetty using both normal and extracted modes. If I have jetty first extract the war file, I can see the source-context.json filesin the WEB-INF/classes directory.
What am I missing?
https://github.com/GoogleCloudPlatform/cloud-debug-java#extra-classpath mentions
you can update the agentPath showing your WEB-INF/class directory.
-agentpath:/opt/cdbg/cdbg_java_agent.so=--cdbg_extra_class_path=/opt/tomcat/webapps/myapp/WEB-INF/classes
For multiple class paths:
-agentpath:/opt/cdbg/cdbg_java_agent.so=--cdbg_extra_class_path=/opt/tomcat/webapps/myapp/WEB-INF/classes:/another/path/with/classes
There are a couple of things going on here.
First, it sounds like you are doing the correct thing with gen-repo-info-file. The debugger agent should pick up the json files from the WEB-INF/classes directory.
The debugger uses fuzzy matching to find source files, so as long as the name of the .java file matches a file in your executable, you should not get that error.
The most likely scenario given the information in your question is that you are attaching the debugger to a launcher process, rather than your actual application. Without further details, I can't absolutely confirm that, though.
If you send us more details at cdbg-feedback#google.com, we can look more closely at your case to see if we can understand exactly what's happening, and potentially improve our documentation, since it sounds like you followed the docs pretty closely.
So, I'm enjoying using composer, but I'm struggling to understand how others use it in relation to a deployment service. Currently I'm using deployhq, and yes, I can set it to deploy and run composer when there is an update to the repo, but this doesn't make sense to me now.
My main composer repo, containing just the json file of all of the packages I want to include in my build, only gets updated when I add a new package to the list.
When I update my theme, or custom extension (which is referenced in the json file), there is no "hook" to update my deployment service. So I have to log in to my server and manually run composer (which takes the site down until it's finished).
So how do others manage this? Should I only run composer locally and include the vendor folder in my repo?
Any answers would be greatly appreciated.
James
There will always be arguments as to the best way to do things such as this and there are different answers and different options - the trick is to find the one that works best for you.
Firstly
I would first take a step back and look at how you are managing your composer.json
I would recommend that all of your packages in composer.json be locked down to the exact version number of the item in Packagist. If you are using github repo's for any of the packages (or they are set to dev-master) then I would ensure that these packages are locked to a specific commit hash! It sounds like you are basically there with this as you say nothing updates out of the packages when you run it.
Why?
This is to ensure that when you run composer update on the server, these packages are taken from the cache if they exist and to ensure that you dont accidentally deploy untested code if one of the modules happens to get updated between you testing and your deployment.
Actual deployments
Possible Method 1
My opinion is slightly controversial in that when it comes to Composer for many of my projects that don't go through a CI system, I will commit the entire vendor directory to version control. This is quite simply to ensure that I have a completely deployable branch at any stage, it also makes deployments incredibly quick and easy (git pull).
There will already be people saying that this is unnecessary and that locking down the version numbers will be enough to ensure any remote system failures will be handled, it clogs up the VCS tree etc etc - I won't go into these now, there are arguments for and against (a lot of it opinion based), but as you mentioned it in your question I thought I would let you know that it has served me well on a lot of projects in the past and it is a viable option.
Possible Method 2
By using symlinks on your server to your document root you can ensure that the build completes before you switch over the symlink to the new directory once you have confirmed the build completed.
This is the least resistance path towards a safe deployment for a basic code set using composer update on the server. I actually use this method in conjunction with most of my deployments (including the ones above and below).
Possible Method 3
Composer can use "artifacts" rather than a remote server, this will mean that you will basically be creating a "repository folder" of your vendor files, this is an alternative to adding the entire vendor folder into your VCS - but it also protects you against Github / Packagist outages / files being removed and various other potential issues. The files are retrieved from the artifacts folder and installed directly from the zip file rather than being retrieved from a server - this folder can be stored remotely - think of it as a poor mans private packagist (another option btw).
IMO - The best method overall
Set up a CI system (like Jenkins), create some tests for your application and have them respond to push webhooks on your VCS so it builds each time something is pushed. In this build you will set up the system to:
run tests on your application (If they exist)
run composer update
generate an artifact of these files (if the above items succeed)
Jenkins can also do an actual deployment for you if you wish (and the build process doesn't fail), it can:
push the artifact to the server via SSH
deploy the artifact using a script
But if you already have a deployment system in place, having a tested artifact to be deployed will probably be one of its deployment scenarios.
Hope this helps :)
I was using a Chrome shortcut with allow-file-access-from-files in the target to work on my three.js student project files. But sometime this morning this stopped working and it appeared Chrome had been updated. I redid the shortcut but no joy.
Part of the project I'm doing is building three.js animation that works in a common browser (for which I chose Chrome).
Is there any way to get Chrome to allow file access again?
Thanks.
The answer I came up with was to use Firefox instead of Chrome changing the security policy as detailed in https://github.com/mrdoob/three.js/wiki/How-to-run-things-locally
Not a perfect answer but with a deadline looming it's the best workable answer for me right now as trying different variations of Chrome, trying Wamp and also Mongoose didn't work. If I had more time I would work out how to use Python or probably node.js as I've seen it mentioned a number of times as being the faster option.
What gman stated is true, using the Chrome flag (and changing Firefox's security policy) does create a big security risk. But only if you use that shortcut (and it's tabs etc.) for anything other than accessing your own local files. I've been scrupulous about not using it for the internet but don't use this method if you can't be strict with yourself.
Ideally I'd recommend beginning any project with node.js.
Gman's answer is good. If you're in windows environment, and use npm for package management the easiest is to install http-server globally:
npm install -g http-server
Then simply run http-server in any of your project directories:
Eg. d:\my_project> http-server
Starting up http-server, serving ./
Available on:
http:169.254.116.232:8080
http:192.168.88.1:8080
http:192.168.0.7:8080
http:127.0.0.1:8080
Hit CTRL-C to stop the server
Easy, and no security risk of accidentally leaving your browser open vulnerable.
DON'T USE THAT FLAG! You're opening yourself to having your online accounts being hacked and your local data stolen. Here are 2 proof of concept examples
Run a simple server.
It's super simple.
Here's one
Here's one.
Here's another.
And another.
They won't take more than a couple of minutes to download and require no configuration
I have been tasked to look into ways to automate the deployment process for our SSRS 2012 reports. Are there any good tools out there? I'm thinking of something along the lines of press a button and the report gets deployed.
Thanks!
To deploy our SSRS reports, we're using this lovely powershell project:
https://github.com/timabell/ssrs-powershell-deploy
Usage:
.\Deploy-SSRSProject.ps1 -path YourReportsProject.rptproj -configuration Release -verbose
or you can use the alternate parameter set:
.\Deploy-SSRSProject\Deploy-SSRSProject.ps1 -path .\AFS.Reports.rptproj -ServerUrl http://localhost/Reportserver -Folder MyReports -DataSourceFolder "MyReports/Data Sources" -DataSetFolder "MyReports/Datasets" -verbose
The full deployment story (for us):
ssrs-powershell-deploy scripts, .rptproj, .rds, .rdl files are all packaged into a nuget package by our build server.
Octopus Deploy extracts the nuget package on our SSRS server and calls Deploy-SSRSProject.ps1
Visual Studio Deployment
Visual Studio is actually really good at automatic deployment. I've used it a number of times with great results. You need to split your solution into separate projects for each folder on the report server and then it will take a bit of time to configure each project & deployment environment. But after that initial time investment it works wonders and when you add a new project you can simply copy the deployment settings for an existing project.
MSDN article: Set Deployment Properties (Reporting Services)
Rs.exe Utility
Alternatively you can use the Rs.exe utility which comes with SSRS. It is a command-line utility used for automatic deployment and administration. I haven't personally use this one, but I know of it. It is my understanding that there are also third party utilities which leverage Rs.exe in order to automate report deployment but I haven't used any of them so I can't recommend any.
More info on MSDN: RS.exe Utility (SSRS)
I'm sure there are also other third-party tools you could get but I haven't ever looked into them. I've always found the Visual Studio deployment functionality sufficient for my needs.
I have done it using devenv which is located in:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE. The ... 10.0 folder is based on the version no. of your Visual Studio so I have only used this version so cannot vouch for anything else. If you view the help /? commandline switch you can see there are options to build and/or deploy a solution.
In brief I used: devenv {solutionfile} /Deploy {configuration} /Project {projectname}.
I did not use any deployment software but I did know how to code in C#.NET so pays to be familiar with System.IO and System.Xml name spaces.
Given the requirement deploy any file (so reports, datasets or datasources) that has been modified within the past 2 week sprint.
So basically my .net code worked as follows (NB: there are ares that you might have to consider first how well do you know how solution and project files work and if you have more than 1 platform - a platform for the uninitiated is a different set of project build and deployment settings):
Read the sln file line by line to get list of projects for the specific platform that are ready to be built/deployed, for simplicity my code assumed only one platform and all projects were to be deployed
The list from 1 gives me the subproject\subproject.rptproj settings in which I can break on the backslash to get the subfolder name from which I can iterate over all files in the project folder and check each file for the LastWritten datetime stamp of the file to determine what files that need to be deployed.
I back-up the entire file (declaration and contents)
If a file has not changed I edit the project file on the fly using xml and remove all unwanted files (ProjectItem's) not to be deployed
If there are dataset or datasource files changed then I also edit the respective configuration section of the project file and modify the particular configuration section accordingly
Run my build solution process i.e. devenv with commandline args (FYI: I did not encounter any .NET exceptions in this step)
Restore my project file
Providing your SSRS solution is configured correctly and the person running the .net commandline solution has permissions to deploy all should be well. Was easy enough to share my commandline solution source code to anyone else in my team to run to avoid having to white-list the exe if your company has employed such restrictions.