I'm exploring the use of Groovy as the default scripting language for my next project. Some basic requirements are:
load and run Groovy scripts, sending params in and getting results out, I know this can be done using GroovyShell or GroovyScriptEngine.
be able to run in debug mode stepping into the statements of the scripts (no need of managing breakpoints but execute statements in the code and take a look and the values of the variables in the current scope).
Yes, this is like a small IDE, but should be integrated into the app that manages running many scripts in parallel, and sending outputs of some scripts to inputs of other scripts (is a pipes and filters architecture http://www.enterpriseintegrationpatterns.com/patterns/messaging/PipesAndFilters.html).
I'm not sure if Groovy alone provides debugging and stepping into groovy code, or Java Platform Debugger Architecture should be used, or if this should be done by embedding an IDE into this system (it might be possible to embed Eclipse components).
These are my main concerns/doubts about the possibilities of using Groovy. any pointers are welcome.
Short answer is "No easy way to embed debugging functionality in an application that I am aware of". Please provide workaround instructions to use companion IDE or start deep research for any open source projects that have embedded script debugger functionality... and become great friends to the related contributing developers :-).
MORE INFORMATION:
Anything is possible when working with open source software. Yes, you can build a debugger that hooks execution of script (assuming you can keep process/threads separate) to step, create/halt at breakpoints, read variables currently in memory, etc.
Example: SmartBear ReadyAPI SoapUI NG PRO v4.6+(?) includes some base debugging embedded in their "Groovy Script" Test Step editor pane. (Disclaimer: SmartBear might have used other language or libraries to build their debugger features. I also am unsure if/when this feature will go to the SoapUI Open Source project - debugging is clearly noted as a PRO (paid) feature.)
Caveats:
Implementing debugger functionality is a MAJOR feature. You need debugger development experience (and/or even more time) to build functionality unrelated to your actual application. Make sure you truly need this embedded debugging before proceeding.
You should start with existing open-source groovy debugger to embed in your application... if one exists. SmartBear SoapUI NG PRO would be a start... but PRO feature is not open source.
I want to know ways or tools that allow instrumentation of code that is to be deployed as a jar or similar, so that when a jar is used it can allow me recording of what underlying source code is used/accessed.
I have come across tools that allow code coverage in Java. But once the application is deployed, how to perform the same at that time?
This will also give me a glimpse that how frequently a certain module or part of code is being used?
You can try free jacoco library. Also you can check dynatrace which is pretty successful but not for free.
https://www.dynatrace.com/capabilities/business-transaction-monitoring/
I am using Selenium and Java to write tests. I was wondering if there is any way that I can run my code in debug mode and then if there is any issue in the code, I pause the application, fix it, recompile it and then run it from the spot that it was paused. My IDE is Eclipse Mars.
Yes, but only in limited cases where the changes to the code are minor. What you are talking about is called hot code replace. The following explanation is taken from the Eclipse Wiki.
Hot code replace (HCR) is a debugging technique whereby the Eclipse
Java debugger transmits new class files over the debugging channel to
another JVM. In the case of Eclipse development, this also applies to
the VM that runs the runtime workbench. The idea is that you can start
a debugging session on a given runtime workbench and change a Java
file in your development workbench, and the debugger will replace the
code in the receiving VM while it is running. No restart is required,
hence the reference to "hot".
HCR has been specifically added as a standard technique to Java to
facilitate experimental development and to foster iterative
trial-and-error coding. HCR only works when the class signature does
not change; you cannot remove or add fields to existing classes, for
instance. However, HCR can be used to change the body of a method. HCR
is reliably implemented only on 1.4.1 VMs and later, or using any
version of the IBM J9 VM. J9 is available in IBM products such as
Websphere Studio Device Developer™.
If HCR does not work for you even in a simple Java application and you
have confirmed that you are running the application on a supported VM
(taking note that the JVM that runs Eclipse may not be the same as the
JVM that is running your Java application), you may not have automatic
building turned on. Make sure that 'Project > Build Automatically' is
checked.
I have a large Java project that uses some Ruby scripts (primarily because of Ruby's support for "yield"). The Ruby code calls Java code which calls more Ruby code. It's very interleaved, but everything is driven from Java.
I'm using embedded jruby-standalone and building a jar-with-dependencies (via maven). I'm using a maven plugin to run jrubyc and generate .java files which maven compiles for me.
When I run the jar-with-dependencies, I can attach my debugger to the Java process with no problems, but I'd really love to be able to debug the Ruby code. Is there a solution for this?
I'm not launching any kind of jruby executable to which I could attach arguments. It's embedded in the jar and invoked via java -jar.
You could use the gem pry-remote.
Unlike pry, it does not require the process to be launched from a terminal (or a terminal emulator if you're on Windows).
It's not really a debugger per se, but if you add binding.remote_pry in your code where you wish to observe and react within that context (you could for example catch an exception), this would put pry in waiting mode for a remote connection, and from another terminal you should be able to connect to this process and debug it.
2 minutes hands-on tutorial is available here.
Drawbacks:
you cannot have 2 pry remote sessions.
your code must contain the right 'debugging' condition
I use this in pre-deployment environments when developing web apps with jruby, h2 and jetty server.
Good luck!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
We have an application which is deployed on JBoss 5.1, JDK 1.6.
We also have scripts written in PowerShell for testing. These scripts access the application using a web-service.
I would like to check the code coverage of the scripts. Any ideas? Most of the tools I saw are checking a JUnit test coverage and I don't see how we can use them.
AFAIK, all code coverage tools use the same concept (I'll omit the reporting and checking part):
First instrument the code (i.e. place markers).
Then run tests to execute the instrumented code (to activate markers and collect data).
For the second step, the common use case is indeed to run JUnit tests but your tests don't have to be JUnit tests. Actually, they don't even have to be automated.
And the instrumented code doesn't have to be executed in the context of a unit test, it can be packaged in a WAR/EAR and deployed on a container (this will just require a bit more work).
For Cobertura, this is what we can read in the Frequently Asked Questions:
Using Cobertura with a Web Application
I have automated tests that use
HttpUnit/HtmlUnit/Empirix/Rational
Robot, can I use Cobertura?
Yes! The process is a bit more
involved, but the concept is the same.
First instrument your compiled
classes. Then create your war file.
Then deploy the war file into your
application server (Tomcat, JBoss,
WebLogic, WebSphere, etc). Now run
your tests.
As your classes are accessed, they
will create a "cobertura.ser" file on
the disk. You may need to dig around a
bit to find it. Cobertura puts this
file in what it considers to be the
current working directory. Typically
this is the directory that the
application server was started from
(for example, C:\Tomcat\bin) Note:
This file is not written to the disk
until the application server exits.
See below for how to work around this.
Now that you know where the
cobertura.ser file is, you should
modify your deploy step so that it
moves the original cobertura.ser to
the appropriate directory in your
application server, and then moves it
back when finished testing. Then run
cobertura-report.
[...]
For Emma, this is what the documentation says:
3.11. How do I use EMMA in {WebLogic, Websphere, Tomcat, JBoss, ...}?
First of all, there is little chance that you will be able to use the on-the-fly mode (emmarun) with a full-blown J2EE container. The reason lies in the fact that many J2EE features require specialized classloading that will happen outside of EMMA instrumenting classloader. The server might run fine, but you will likely get no coverage data.
Thus, the correct procedure is to instrument your classes prior to deployment (offline mode). Offline instrumentation always follows the same compile/instrument/package/deploy/get coverage/generate reports sequence. Follow these steps:
use EMMA's instr tool to instrument the desired classes. This can be done as a post-compilation step, before packaging. However, many users also find it convenient to let EMMA process their jars directly (either in-place, using overwrite mode, or by creating separate instrumented copies of everything, in fullcopy mode);
do your J2EE packaging as normal, but do not include emma.jar as a lib at this level, that is, within your .war, .ear, etc;
locate whichever JRE is used by the container and copy emma.jar into its /lib/ext directory. If that is impossible, add emma.jar to the server classpath (in a server-specific way);
deploy your instrumented classes, .jars, .wars, .ears, etc and exercise/test your J2EE application via your client-side testcases or interactively or whichever way you do it;
to get a coverage dump file, you have three options described in What options exist to control when EMMA dumps runtime coverage data?. It is highly recommended that you use coverage.get control command with the ctl tool available in v2.1.
For clover, check the Working with Distributed Applications page.
I use emma coverage tool integrated with unit testing project build phase, however, tool's documentation says that it's fairly simple to get code coverage at situation you described.
I suggest jacoco, as it does not require source code modifications.
Check out Measuring Code Coverage in (Tomcat) Java Applications with a GreyBox Harness
Code cover is a great tool. For your case you should use command-line interface, that might you incorporate with existing PowerShell scripts.