Linux Mint 2.1 “Bea”

Linux Mint 2.1 codename “Bea” is out and available for download :)

Many thanks to all the people who contributed to the project and to the users who posted their feedback and suggestions on the forums. Bea is a huge step forward and comes with a lot of changes compared to the last release.

New Software

Two new applications made their way into Linux Mint:

* OpenOffice 2.1-Impress (Calc and Writer also got upgraded to version 2.1)
* Xchat-gnome


Better desktop

This is probably the biggest improvement in Bea: A brand new desktop. Linux Mint 2.1 comes with mintDesktop, which adds a lot of desktop improvements:

* Quick access to the computer and home places
* Quick access to the terminal from the context menu
* Ability to delete files directly without sending them to the Trash
* mintDesktop home folders
* Beagle search
* Tomboy notes
* Network manager

Better Wifi support

Bea comes with mintWifi, which purpose is to allow you to configure your wireless card without an Internet connection. mintWifi comes with the following:

* Ndiswrapper and Ndisgtk
* Cabextractor and unshield
* Tutorials to install and configure your Wifi card
* A collection of Wifi drivers to support about 40 different wireless card models

Better branding

* Bea comes with new artwork: new LiveCD splash, new usplash and GDM screens.
* Help is now “one click away”. As our community is growing it seemed important that users could find help and support in the easiest possible way. To achieve this Xchat-Gnome was modified to automatically connect to the Linux Mint IRC channel, and Firefox now features Linux Mint bookmarks pointing at the website and forums.

Better Web browsing

Web browsing was good in Barbara, but as some of you pointed out, it wasn’t good enough:

* Realplayer 10 was replaced with the Mplayer plugins so you can now enjoy Quicktime, AVI, MPG and a lot of other web content.
* The Flash plugin was upgraded to version 9 Beta 2.
* Support for ipv6 was disabled to make your Internet connection and Web browsing faster
* Firefox 2.0 was tweaked so that it does go back to the previous page when you press the backspace key

And a few surprises…

* For those of you who have nvidia cards there’s a little surprise in Bea called envy
* For those of you who like to mount stuff, PyMou was added to the command line
* For those of you who love using Amarok we added support for MusicBrainz tagging
* For those of you who need to extract RAR archives we included unrar
* For those of you who really like Flash, we included the Flash player
* And for those of you who like playing with the terminal, we put a little surprise in there too

Accelerate Your Java Web Service Development with XFire

SOAP Web Services have been around for a number of years now. For many years, the two main Java-based SOAP frameworks were Apache Axis and Sun's JAX-WS. A new Java-based SOAP framework by Codehaus called XFire now provides an even simpler way to develop SOAP web services and clients. The first article in this series will create a simple SOAP client using XFire, demonstrating how simple it is to work with this Java SOAP framework. The second article will use XFire to create a web service implementation.

XFire: SOAP Web Services Simplified

XFire is a next-generation Java SOAP framework. It makes service-oriented development approachable through its easy-to-use API and support for standards. It is also highly performant because it is built on a low-memory, StAX-based model. XFire can be used to create SOAP web service implementations and SOAP web service clients. Some important features of XFire are:

• Support for important Web Service standards—SOAP, WSDL, WS-I Basic Profile, WS-Addressing, WS-Security, and so forth.
• High performance SOAP Stack
• Pluggable bindings POJOs, XMLBeans, JAXB 1.1, JAXB 2.0, and Castor support
• JSR 181 API to configure services via Java 5 and 1.4 (Commons attributes JSR 181 syntax)
• Support for many different transports—HTTP, JMS, XMPP, In-JVM, and so on.
• Embeddable and Intuitive API
• Spring, Pico, Plexus, and Loom support.
• JBI Support
• Client and server stub generation
• JAX-WS early access support

Downloading XFire

The first thing you will want to do is get the latest XFire distribution, which is XFire 1.2.6. You can download the xfire-distribution-1.2.6.zip file from the XFire Download page. Once you have downloaded it, you can unzip it to a directory of your choice. I extract it to my C: drive, creating a directory C:xfire-1.2.6.

Downloading Java

For this example, I will use Java SE 5, specifically version 1.5.0_06. You can download the latest Java SE version from the Sun Java Download page. You can follow the installation instructions and install Java SE on to your machine. You also will want to set a JAVA_HOME environment variable as well as add the JAVA_HOMEbin directory to your PATH, so you can run the 'javac' and 'java' commands.

Downloading Ant

To compile and build your Java code, you will use the Apache Ant build tool. You can download the latest version of Ant, version 1.7.0 from the Ant Download page. All that needs to be done is unzip the file to a directory. I extract it to my C: drive, creating a directory C:ant-1.7.0. You also will need to set an ANT_HOME environment variable as well as add the ANT_HOMEbin to your PATH, so you can run the 'ant' command. For this example, I will be using an older version, 1.6.5.

Downloading Eclipse

For this example, I will use the Eclipse IDE to do my development. I am currently running Eclipse version 3.2.2. You can download the latest version of Eclipse from the Eclipse Download page and follow the installation instructions and install Eclipse on to your machine.

Creating Your XFireDemo Project in Eclipse

Create an XFireDemo Java project in Eclipse. Within this project, create the 'bin', 'src', 'lib' subdirectories, as well as a 'build.xml' file. Copy the C:xfire-1.2.6xfire-all-1.2.6.jar file and C:xfire-1.2.6lib*.jar files to the XFireDemo project 'lib' directory. Once you are done, your project should look like this:

Figure 1:XFireDemo Eclipse Project

Filling in the Ant build.xml File

You are going to use Ant to build your XFire test, so you need to create your build.xml file. The build file contains three targets: one to clean the build, called 'clean'; one to generate our SOAP client Java classes from the web service WSDL definition, called 'wsgen'; and one to compile the project, called 'compile'. Here is the build.xml file with the 'clean' and 'compile' targets filled in:

You will compile your Java source files from the 'src' directory, creating Java classes in the 'bin' directory.

XMethods Stock Quote Web Service

You are going to create a SOAP client for the XMethods Stock Quote web service. This simple SOAP web service takes a String parameter representing a stock company symbol and returns the stock quote for this symbol. This web service has a WSDL located at the URL http://www.webservicex.net/stockquote.asmx. You will use XFire to generate SOAP client Java classes that you can use to access this web service.

Generating SOAP Client Java Classes from a WSDL Using XFire

XFire provides an Ant task that allows a user to generate the Java classes for the SOAP client of a web service. It does this by inspecting a WSDL definition for that web service. You are going to point XFire to the XMethods Stock Quote WSDL URL and have it generate your SOAP client Java classes for you. To do this, you need to set up your 'wsgen' Ant task in our build.xml file. Add the following to the 'build.xml' file:

You define a 'wsdlurl' property that contains your StockQuote web service WSDL URL. You also specify your Java compilation classpath by using a path variable 'compile.classpath'. You define the XFire built-in 'wsgen' Ant task definition. You then specify your 'wsgen' ant target that uses the XFire 'wsgen' taskdef, pointing to the 'wsdlurl', to generate your StockQuote web service SOAP client Java classes in the 'net.xmethods.services.stockquote' package. When you run this task, you will see the following new Java classes in your project:

Figure 2:StockQuote SOAP web service client Java classes generated by XFire

Coding the StockQuote Web Service Client

You create a Java class file called XFireClientTest in the 'src' directory. The 'src' directory should now look like this:

Figure 3:XFireClientTest Java class

Fill in the XFireClientTest.java file with the following Java code:

import net.xmethods.services.stockquote.StockQuoteClient;
import net.xmethods.services.stockquote.StockQuoteSoap;

public class XFireClientTest
{
 public static void main(String[] args) {
    StockQuoteClient client = new StockQuoteClient();
    StockQuoteSoap service = client.getStockQuoteSoap();
    String quote = service.getQuote("HOT");
    System.out.println(quote);
 }
}

Your client gets the client proxy for the StockQuote service. It then uses it to get the StockQuote service and call the 'getQuote()' service method, passing in the company symbol of 'HOT'. It then prints out the result to the console. That is all there is for you to code; XFire has generated all the other marshalling code that will convert your input parameter into a SOAP request.

Compiling the XFireDemo Project

Now that you have your Stock Quote web service client, you can go ahead and compile your project using Ant. Running 'ant build.xml' produces the following output, indicating that it compiled your source code and created your XFireClientTest and supporting class files in the 'bin' directory:

Buildfile: C:Documents and SettingsdominicworkspaceXFireDemo
            build.xml
clean:
 [delete] Deleting 8 files from C:Documents and Settingsdominic
          workspaceXFireDemobin
wsgen:
 [wsgen] Jun 30, 2007 5:02:46 PM
         org.codehaus.xfire.gen.Wsdl11Generator generate
 [wsgen] INFO: Generating code for WSDL at
         http://www.webservicex.net/stockquote.asmx?WSDL with a
         base URI of http://www.webservicex.net/stockquote.asmx?WSDL
 [wsgen] Jun 30, 2007 5:02:51 PM
         org.codehaus.XFire.gen.jsr181.AbstractServiceGenerator
         generate
 [wsgen] INFO: Creating class
         net.xmethods.services.stockquote.StockQuoteSoap
 [wsgen] Jun 30, 2007 5:02:51 PM
         org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator
         generate
 [wsgen] INFO: Creating class
         net.xmethods.services.stockquote.StockQuoteImpl
 [wsgen] netwebservicexGetQuote.java
 [wsgen] netwebservicexGetQuoteResponse.java
 [wsgen] netwebservicexObjectFactory.java
 [wsgen] netwebservicexpackage-info.java
 [wsgen] netxmethodsservicesstockquoteStockQuoteClient.java
 [wsgen] netxmethodsservicesstockquoteStockQuoteImpl.java
 [wsgen] netxmethodsservicesstockquoteStockQuoteSoap.java
compile:
 [javac] Compiling 8 source files to C:Documents and Settings
         dominicworkspaceXFireDemobin
 [javac] Note: C:Documents and Settingsdominicworkspace
         XFireDemosrcnetxmethodsservicesstockquote
         StockQuoteClient.java uses unchecked or unsafe operations.
 [javac] Note: Recompile with -Xlint:unchecked for details.
BUILD SUCCESSFUL
Total time: 14 seconds

Running the StockQuote Service SOAP Client Test

You can run your client directly from Eclipse by right-clicking the XFireClientTest class and selecting 'Run As->Java Application':

Click here for a larger image.

Figure 4:Running XFireClientTest in Eclipse

When you run the SOAP client test class, XFireClientTest, using a company symbol of 'HOT' (Starwood Hotels and Resorts), you will get the following response from the Stock Quote web service, indicating a successful test:

 
    HOT
    67.07
    6/29/2007
    4:00pm
    -1.13
    68.04
    68.77
    66.035
    3752226
    14.427B
    68.20
    -1.66%
    49.68 - 74.35
    5.237
    13.02
    STARWOOD HOTELS&R
 

Conclusion

This article took a look at XFire, a Java SOAP framework that makes working with web services fast and simple. You created a SOAP client and saw how easy it is to use XFire. In the next article in this XFire series, you will create your own SOAP web service using XFire.

References

• Codehaus XFire: http://xfire.codehaus.org/
• Sun Java: http://java.sun.com/
• Apache Ant: http://ant.apache.org/
• Eclipse: http://www.eclipse.org/
• XMethods: http://www.xmethods.net/
• SilvaSoft, Inc. weblog: http://jroller.com/page/silvasoftinc

About the Author

Dominic Da Silva (http://www.dominicdasilva.com/) is the President of SilvaSoft, Inc., a software consulting company specializing in Java- and Ruby-based web and web services development. He has worked with Java since the year 2000 and is a Linux user from the 1.0 days. He is also Sun Certified for the Java 2 platform. Born on the beautiful Caribbean island of Trinidad and Tobago, he now makes his home in sunny Orlando, Florida.

Code Coverage for Free: How to Use EMMA

In this article you will learn how to configure Open Source framework EMMA to work with a web-based application.

Why Do You Need Code Coverage?

How do you know if the code you have written is being executed during regression or unit testing? One way is to use a debugger. Another way is to log every line of code. Yet another way is to compare the expected results of the test with the actual results. The latter usually suffices. All three methods are "somewhat" potent, but nonetheless, all three methods are not enough.

The first case will work in a small, non-repeatable test. The second method clutters your code and the verification process is labor intensive and ineffective. Only the third method is generally accepted by the IT and user community. The third method relies on the test author to cover ALL conditions and prepare test data in such a way that all test conditions are met. You put your trust into the test author's hands. Now, consider the following situation:

You are testing a method that accepts two parameters. It returns false if the first parameter is 1 or the second parameter is 1. Otherwise, the method returns true. The test author creates three test cases to cover three possible scenarios:

1. A is 1; the expected result is false.
2. B is 1; the expected result is false.
3. Both A and B are not 1; the expected result is true.

Figure 1

For the test data, the test author creates three records corresponding to each case:

1. A = 1, B = 0
2. A = 0, B = 1
3. A = 2, B = 2

The above test data in conjunction with three test cases covers all exit points of the returnSomething () method. Now, suppose the test author made a mistake and created the following test data:

1. A = 1, B = 0
2. A = 1, B = 1
3. A = 2, B = 1

What happens now? The second test case return false, which matches our expected result, but Line 4 had never been executed. This is precisely why you need a code coverage tool.

Why EMMA?

I have chosen EMMA as a code coverage tool of choice because:

1. It is open-source 100% Java.
2. It has a large market share compared with the other open source coverage tools.

Note: See other open source coverage tools here: http://java-source.net/open-source/code-coverage.

3. It is easy to use (once you figure out how to use it).
4. It has most of the features that one needs from the code coverage tool:
1. It has multiple report type formats.
2. It has class instrumentation that can be done offline and on the fly.
3. It can be used in an enterprise environment.
4. It has ANT support.
5. It includes the ability to drill down to class, method, and lines of code.
5. It is free for both open-source and commercial development.

Emma's home page is http://emma.sourceforge.net/.

How-To Overview

This overview explains how to configure EMMA for a web-based Java application. It entails:

1. Recompilation of Java classes using the debug="on" option.
2. Off-line instrumentation of application-specific Java classes by using the EMMA <instr> command.
3. Extracting Java coverage dump from JVM by using the ANT command.
4. Building code coverage report by using the EMMA <report> command.

All development for this how-to is done within the IBM Rational Software Development Platform 6.0.1 and Websphere 5.1 test environment.

Get JAR Files

Emma jar files (emma.jar and emma_ant.jar) can be downloaded here: http://sourceforge.net/project/showfiles.php?group_id=108932&package_id=117768. You want to get version 2.1.5320 just to be on board with my example.

Import Emmarun.zip into Your Workspace

You can find a link to the download of EmmaRun.zip at the end of this article. The zip file contains one servlet (EmmaTestServlet.java), deployment descriptor (web.xml), one jsp file (input.jsp), and ANT files for running EMMA tools (1_emma_compile.xml, 2_emma-instument.xml, 3_emma_copyfiles.xml, 4_emma-extract-covarage.xml, and 5_emma_report.xml).

Go to FILE → IMPORT → ZIP FILE and follow further instructions on the screen.

Figure 2

Add JAR Files to Your Application Server Classpath

Add Emma.jar and emma_ant.jar to application server classpath Locate Application Server for your web application → Select Environment Tab → under Class Path, click on "Add External Jars", and add emma.jar and emma_ant.jar.

Figure 3

Recompile Classes for Code Coverage

Locate the 1_emma-compile.xml Ant script and execute it. The output should look like this:

Figure 4

This script compiles your EmmaTestServlet.java and places the class file into a emma_classes directory under WebContent/WEB-INF/. The only thing to note in this script is that you do compile with the debug="on" option.

Instrument Classes for Code Coverage

Locate the 2_emma-instument.xml Ant script and execute it. The output should look like this:

Figure 5

This script performs the following steps:

1. It resets this demo project to a clean state.
2. It turns on EMMA instrumentation.
3. It runs the EMMA instrumentation by taking the class files produced by 1_emma-compile.xml ANT script and producing metadata.em instrumentation file and EMMA-instrumented class files.

Copy Classes

Locate the 3_emma-copyfiles.xml Ant script and execute it. This script copies instrumented class files from the "emma_intr_classes" directory to the "classes" directory. This is the output of the script:

Figure 6

Execute Your Example

Now that you have recompiled, instrumented, and copied class files to the classes directory, you can start executing your application. In this step, you will call your application several times. As I mentioned earlier, your test application consists of one servlet, EmmaTestServlet.java, and one jsp, input.jsp. The servlet accepts two parameters from the JSP and, based on these parameters, returns true or false. Repeat the same steps you saw at the beginning of the article:

1. Parameter 1 = 1, Parameter 2 = 0
2. Parameter 1 = 0, Parameter 2 = 1
3. Parameter 1 = 2, Parameter 2 = 2

Figure 7

Extract Coverage Dump

Locate the 4_emma-extract-covarage.xml ANT Script and execute it. By using the command, this script communicates with a JVM running EMMA-instrumented classes via a TCP socket. It downloads current coverage data from a JVM at a given TCP address and saves it into a local file, 'mycoverage.ec'. The output of the script should look like this:

Figure 8

Locate the 5_emma_report.xml ANT Script and execute it. This script executes a EMMA command- offline coverage report generator. It reads in a 'metadata.em' class metadata (produced by the instrumentation step) and runtime 'mycoverage.ec' coverage data (produced by extracting the coverage dump step) and generates a coverage report. The execution output should look like this:

Figure 9

View Report

You finally can open the generated index.html file in the browser to review your results. The report shows that 100% of your code has been executed.

Figure 10 (overall coverage summary)

Figure 11 (coverage summary for source file [EmmaTestServlet.java])

Conclusion

The example that is explained above reveals only a part of EMMA's full functionality, but I hope it will help you get started with this great framework. The framework provides many customization options that you can read about in the help files provided by the author of the framework.

Download

Download the source code for this article here.

References

• http://emma.sourceforge.net/
• http://java-source.net/open-source

About the Author

Aleksey Shevchenko has been working with object-oriented languages for over seven years. For the past four years, he has served as a technical lead and a project manager. Aleksey has been implementing Enterprise IT solutions for Wall Street and the manufacturing and publishing industries.