e.g. just found out that both WAS server and Skype uses port 80 by default
1. get the PID running on each of the port
use netstat - anobv
2. find which exe, dll running has the PID xxxx
tasklist /svc /FI "PID eq xxxx"
Saturday, March 26, 2011
Friday, March 18, 2011
EMMA remote
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:
1. 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);
2. 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;
3. 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);
4. 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;
5. 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.
see
http://stackoverflow.com/questions/1660141/java-measure-code-coverage-for-remote-scripting-tests
http://colin2wang.javaeye.com/blog/627618
http://sourceforge.net/project/shownotes.php?release_id=336859
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:
1. 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);
2. 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;
3. 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);
4. 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;
5. 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.
see
http://stackoverflow.com/questions/1660141/java-measure-code-coverage-for-remote-scripting-tests
http://colin2wang.javaeye.com/blog/627618
http://sourceforge.net/project/shownotes.php?release_id=336859
Subscribe to:
Posts (Atom)